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You know you don’t want to reinvent the wheel (or worse, a flat tire), so 
you look to design patterns — the lessons learned by those who’ve faced 
the same software design problems. With design patterns, you get to take 
advantage of the best practices and experience of others, so that you 
can spend your time on...something else. Something more challenging. 
Something more complex. Something more fun. You want to learn: 

• The patterns that matter 

• Wtien to use them, and why 

• How to apply them to your own designs, right now 

• When not to use them (how to avoid pattern fever) 

• OO design principles on which patterns are based 

Most importantly, you want to learn design patterns in a way that won’t put 
you to sleep. If you’ve read a Head First book, you know what to expect — 
a visually rich format designed for the way your brain works. Using the latest 
research in ncurobiology, cognitive science, and learning theory, Head 
First Design Patterns will load patterns into your brain in a way that sticks. 
In a way that makes you better at solving software design problems, and 
better at speaking the language of patterns with others on your team. 

Eric Freeman and Elisabeth Freeman are authors, educators, and tech¬ 
nology innovators. After four years leading digital media and Internet 
efforts at the Walt Disney Company ， they’re applying some of that 
pixie dust to their own media, including this book. Eric and Elisabeth 
both hold computer science degrees from Yale 
University: Elisabeth holds an M.S. degree and 
Eric a Ph.D. 

Kathy Sierra (founder of javaranch.com) and 
Bert Bates are the creators of the best-selling 
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Praise for Head First Design Patterns 


“I received the book yesterday and started to read it on the way home... and I couldn’t stop. I took it to the 
gym and I expect people saw me smiling a lot while I was exercising and reading. This is tres ‘cool’. It is 
fun but they cover a lot of ground and they are right to the point. I’m really impressed.” 

Erich Gamma, IBM Distinguished Engineer, 
and co-author of Design Patterns 

c “Head First Design Patterns 5 manages to mix fun, belly-laughs, insight, technical depth and great practical 
advice in one entertaining and thought provoking read. Whether you are new to design patterns, or have 
been using them for years, you are sure to get something from visiting Objectville.” 

Richard Helm, coauthor of “Design Patterns” with rest of the 
Gang of Four - Erich Gamma, Ralph Johnson and John Vlissides 

“I feel like a thousand pounds of books have just been lifted off of my head.” 

Ward Cunningham, inventor of the Wiki 
and founder of the Hillside Group 

“This book is close to perfect, because of the way it combines expertise and readability. It speaks with 
authority and it reads beautifully. It’s one of the very few software books I’ve ever read that strikes me as 
indispensable. (I’d put maybe 10 books in this category, at the outside.)” 

David Gelernter, Professor of Computer Science, 

Yale University and author of “Mirror Worlds” and “Machine Beauty” 

“A Nose Dive into the realm of patterns, a land where complex things become simple, but where simple 
things can also become complex. I can think of no better tour guides than the Freemans.” 

Miko Matsumura，Industry Analyst, The Middleware Company 
Former Chief Java Evangelist, Sun Microsystems 

u l laughed, I cried, it moved me.” 

Daniel Steinberg, Editor-in-Chief, java.net 

“My first reaction was to roll on the floor laughing. After I picked myself up, I realized that not only is the 
book technically accurate, it is the easiest to understand introduction to design patterns that I have seen.” 

— Dr. Timothy A. Budd，Associate Professor of Computer Science at 
Oregon State University and author of more than a dozen books, 
including “C++ for Java Programmers” 

“Jerry Rice runs patterns better than any receiver in the NFL, but the Freemans have out run him. 
Seriously...this is one of the funniest and smartest books on software design I’ve ever read.” 

Aaron LaBerge, VP Technology, ESPN.com 



More Praise for Head First Design Patterns 


“Great code design is, first and foremost, great information design. A code designer is teaching a com¬ 
puter how to do something, and it is no surprise that a great teacher of computers should turn out to be 
a great teacher of programmers. This book’s admirable clarity, humor and substantial doses of clever 
make it the sort of book that helps even non-programmers think well about problem-solving.” 

—— Cory Doctorow, co-editor of Boing Boing 

and author of ‘ 6 Down and Out in the Magic Kingdom’’ 
and “Someone Comes to Town, Someone Leaves Town” 


“There’s an old saying in the computer and videogame business - well, it can’t be that old because the 
discipline is not all that old - and it goes something like this: Design is Life. What’s particularly curious 
about this phrase is that even today almost no one who works at the craft of creating electronic games 
can agree on what it means to “design” a game. Is the designer a software engineer? An art director? 
A storyteller? An architect or a builder? A pitch person or a visionary? Can an individual indeed be in 
part all of these? And most importantly, who the %$!#&* cares? 

It has been said that the “designed by” credit in interactive entertainment is akin to the “directed by” 
credit in filmmaking, which in fact allows it to share DNA with perhaps the single most controversial, 
overstated, and too often entirely lacking in humility credit grab ever propagated on commercial art. 
Good company, eh? Yet if Design is Life, then perhaps it is time we spent some quality cycles thinking 
about what it is. 

Eric and Elisabeth Freeman have intrepidly volunteered to look behind the code curtain for us in 
“Head First Design Patterns.” I’m not sure either of them cares all that much about the PlayStation 
or X-Box, nor should they. Yet they do address the notion of design at a significantly honest level such 
that anyone looking for ego reinforcement of his or her own brilliant auteurship is best advised not to 
go digging here where truth is stunningly revealed. Sophists and circus barkers need not apply. Next 
generation literati please come equipped with a pencil.” 

Ken Goldstein, Executive Vice President & Managing Director, 

Disney Online 


“Just the right tone for the geeked-out, casual-cool guru coder in all of us. The right reference for 
practical development strategies — gets my brain going without having to slog through a bunch of tired, 
stale professor-speak. 55 

— Travis Kalanick, Founder of Scour and Red Swoosh 
Member of the MIT TR100 


“This book combines good humors, great examples, and in-depth knowledge of Design Patterns in 
such a way that makes learning fun. Being in the entertainment technology industry, I am intrigued 
by the Hollywood Principle and the home theater Facade Pattern, to name a few. The understanding 
of Design Patterns not only helps us create reusable and maintainable quality software, but also helps 
sharpen our problem-solving skills across all problem domains. This book is a must read for all com¬ 
puter professionals and students.” 

Newton Lee, Founder and Editor-in-Chief, Association for Computing 
Machinery’s (ACM) Computers in Entertainment (acmcie.org) 



More Praise for Head First Design Patterns 


“If there’s one subject that needs to be taught better, needs to be more fun to learn, it’s design patterns. 
Thank goodness for Head First Design Patterns. 


From the awesome Head First Java folks, this book uses every conceivable trick to help you understand 
and remember. Not just loads of pictures: pictures of humans, which tend to interest other humans. 
Surprises everywhere. Stories, because humans love narrative. (Stories about things like pizza and 
chocolate. Need we say more?) Plus, it’s darned funny. 

It also covers an enormous swath of concepts and techniques, including nearly all the patterns you’ll 
use most (observer, decorator, factory, singleton, command, adapter, facade, template method, iterator, 
composite, state, proxy). Read it, and those won’t be ‘just words ’： they’ll be memories that tickle you, 
and tools you own.” 

— Bill Camarda，READ ONLY 


“After using Head First Java to teach our freshman how to start programming, I was eagerly waiting to 
see the next book in the series. Head First Design Patterns is that book and I am delighted. I am sure 
it will quickly become the standard first design patterns book to read, and is already the book I am 
recommending to students.” 

—— Ben Bederson，Associate Professor of Computer Science & Director of the 
Human-Computer Interaction Lab, University of Maryland 


“Usually when reading through a book or article on design patterns I’d have to occasionally stick myself in 
the eye with something just to make sure I was paying attention. Not with this book. Odd as it may sound, 
this book makes learning about design patterns fun. 

While other books on design patterns are saying, ‘Buehler... Buehler... Buehler... 5 this book is on the float 
belting out c Shake it up, baby!’” 

— Eric Wuehler 


“I literally love this book. In fact, I kissed this book in front of my wife.” 

— Satish Kumar 


Praise for the Head First approach 


c Java technology is everywhere ― in mobile phones, cars, cameras, printers, games, PDAs, ATMs, smart 
cards, gas pumps, sports stadiums, medical devices, Web cams, servers, you name it. If you develop 
software and haven’t learned Java, it’s definitely time to dive in — Head First.” 

— Scott McNealy, Sun Microsystems Chairman, President and CEO 


“It’s fast, irreverent, fun, and engaging. Be careful~~you might actually learn something!” 

— Ken Arnold, former Senior Engineer at Sun Microsystems 
Co-author (with James Gosling, creator of Java )， 

“The Java Programming Language” 
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Welcome to Design Patterns 

Someone has already solved your problems, in this chapter, 

you’ll learn why (and how) you can exploit the wisdom and lessons learned by 
other developers who’ve been down the same design problem road and survived 
the trip. Before we’re done, we’ll look at the use and benefits of design patterns, 
look at some key 00 design principles, and walk through an example of how one 
pattern works. The best way to use patterns is to load your brain with them and 
then recognize places in your designs and existing applications where you can 
apply them. Instead of code reuse, with patterns you get experience reuse. 


Remember, knowing 
concepts like abstraction, 
inheritance, and polymorphism do 
not make you a good object oriented 
designer. A design guru thinks 
about how to create flexible 
designs that are maintainable 
and that can cope with 
change. 
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Keeping your Objects in the Know 

Don’t miss out when something interesting happens! 

We’ve got a pattern that keeps your objects in the know when something they 
might care about happens. Objects can even decide at runtime whether they 
want to be kept informed. The Observer Pattern is one of the most heavily used 
patterns in the JDK, and it’s incredibly useful. Before we’re done, we’ll also look 
at one to many relationships and loose coupling (yeah, that’s right, we said 
coupling). With Observer, you’ll be the life of the Patterns Party. 
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The Weather Monitoring application 
Meet the Observer Pattern 
Publishers + Subscribers = Observer Pattern 
Five minute drama: a subject for observation 
The Observer Pattern defined 
The power of Loose Coupling 
Designing the Weather Station 
Implementing the Weather Station 
Using Java’s built-in Observer Pattern 
The dark side of java.util.Observable 
Tools for your Design Toolbox 
Exercise Solutions 
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3 Decorating Objects 

Just call this chapter “Design Eye for the Inheritance 

Guy.” We’ll re-examine the typical overuse of inheritance and you’ll learn how 
to decorate your classes at runtime using a form of object composition. Why? 
Once you know the techniques of decorating, you’ll be able to give your (or 
someone else’s) objects new responsibilities without making any code changes 
to the underlying classes. 
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Baking with OO Goodness 

Get ready to cook some loosely coupled OO designs. 

There is more to making objects than just using the new operator. You’ll learn 
that instantiation is an activity that shouldn’t always be done in public and can 


often lead to coupling problems. And you don’t want that, do you? Find out how 
Factory Patterns can help save you from embarrasing dependencies. 
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5 One of a Kind Objects 

The Singleton Pattern: your ticket to creating one-of-a- 
kind objects, for which there is only one instance. You 

might be happy to know that of all patterns, the Singleton is the simplest in terms 
of its class diagram; in fact the diagram holds just a single class! But don’t get 
too comfortable; despite its simplicity from a class design perspective, we’ll 
encounter quite a few bumps and potholes in its implementation. So buckle 
up — this one’s not as simple as it seems... 
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Encapsulating Invocation 

In this chapter we take encapsulation to a whole new 
level: we’re going to encapsulate method invocation. 

That's right, by encapsulating invocation we can crystallize pieces of computation 
so that the object invoking the computation doesn’t need to worry about how to do 
things; it just uses our crystallized method to get it done. We can also do some 
wickedly smart things with these encapsulated method invocations, like save 
them away for logging or reuse them to implement undo in our code. 
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7 Being Adaptive 

In this chapter we’re going to attempt such impossible 
feats as putting a square peg in a round hole, sound impossible? 
Not when we have Design Patterns. Remember the Decorator Pattern? We 
wrapped objects to give them new responsibilities. Now we’re going to wrap some 
objects with a different purpose: to make their interfaces look like something they’re 
not. Why would we do that? So we can adapt a design expecting one interface to a 
class that implements a different interface. That’s not all, while we’re at it we’re going 
to look at another pattern that wraps objects to simplify their interface. 
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8 Encapsulating Algorithms 

We’ve encapsulated object creation, method invocation, 
complex interfaces, ducks, pizzas... what could be next? 

We’re going to get down to encapsulating pieces of algorithms so that subclasses can 
hook themselves right into a computation anytime they want. We’re even going to 
learn about a design principle inspired by Hollywood. 
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Well-Managed Collections 

There are lots of ways to stuff objects into a collection. 

Put them in an Array, a Stack, a List, a Map, take your pick. Each has its own 
advantages and tradeoffs. But when your client wants to iterate over your objects, 


are you going to show him your implementation? We certainly hope not! That just 
wouldn’t be professional. Don’t worry — in this chapter you’ll see how you can let 
your clients iterate through your objects without ever seeing how you store your 
objects. You’re also going to learn how to create some super collections of objects 
that can leap over some impressive data structures in a single bound. You’re also 
going to learn a thing or two about object responsibility. 
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I A ■ A little known fact: the Strategy and State Patterns were 
I twins separated at birth. As you know, the Strategy Pattern went on 

to create a wildly successful business around interchangeable algorithms. State, 
however, took the perhaps more noble path of helping objects learn to control their 
behavior by changing their internal state. He’s often overheard telling his object 
clients, “just repeat after me, I’m good enough, I’m smart enough, and doggonit …” 
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ja Controlling Object Access 

Ever play good cop, bad cop? You’re the good cop and you provide 
■ ■ all your services in a nice and friendly manner, but you don’t want everyone 

asking you for services, so you have the bad cop control access to you. That’s 
what proxies do: control and manage access. As you’re going to see there are 
lots of ways in which proxies stand in for the objects they proxy. Proxies have 
been known to haul entire method calls over the Internet for their proxied objects; 
they’ve also been known to patiently stand in the place for some pretty lazy 
objects. 
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Patterns of Patterns 

f Who would have ever guessed that Patterns could work 

J together? You’ve already witnessed the acrimonious Fireside Chats (and be 
thankful you didn’t have to see the Pattern Death Match pages that the publisher 
forced us to remove from the book so we could avoid having to use a Parent’s 
Advisory warning label), so who would have thought patterns can actually get along 
well together? Believe it or not, some of the most powerful 00 designs use several 
patterns together. Get ready to take your pattern skills to the next level; it’s time for 
Compound Patterns. Just be careful — your co-workers might kill you if you’re struck 
with Pattern Fever. Compound Patterns 
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Patterns in the Real World 

Ahhhh, now you’re ready for a bright new world filled with 

Design Patterns. But, before you go opening all those new doors of opportunity 
we need to cover a few details that you’ll encounter out in the real world — things get a 
little more complex out there than they are here in Objectville. Come along, we’ve got 


a nice guide to help you through the transition... 
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Appendix: Leftover Patterns 

Not everyone can be the most popular, a lot has changed in 
the last 10 years. Since Design Patterns: Elements of Reusable Object-Oriented 
Software first came out, developers have applied these patterns thousands of times. 
The patterns we summarize in this appendix are full-fledged, card-carrying, official 
GoF patterns, but aren’t always used as often as the patterns we’ve explored so 
far. But these patterns are awesome in their own right, and if your situation calls for 
them, you should apply them with your head held high. Our goal in this appendix is 
to give you a high level idea of what these patterns are all about. 
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how to use this book 


Who is this book for? 


If you can answer “yes” to all of these: 

Do you know Java? (You don’t need to be a guru.) 

(2) Do you want to learn, understand, remember, and 
apply design patterns, including the 00 design 
principles upon which design patterns are based? 




( 3 ^ Do you prefer stimulating dinner party conversation 
to dry, dull, academic lectures? 


this book is for you. 


Who should probably back away from this book? 

If you can answer “yes” to any one of these: 

Are you completely new to Java? 

(You don’t need to be advanced, and even if you 
don’t know Java, but you know C#, you’ll probably 
understand at least 80% of the code examples. You 
also might be okay with just a C++ background.) 

(2) Are you a kick-butt 00 designer/developer looking 
for a reference book? 

( 3 ) Are you an architect looking for enterprise design 
patterns? 

(4) Are you afraid to try something different? 

Would you rather have a root canal than mix 
stripes with plaid? Do you believe that a technical 
book can’t be serious if Java components are 
anthropomorphized? c 


this book is not for you. 


"'avke-ti K)9 ： -this book is 
anyone With a dvedi-t tay-dJ 
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We know what you're thinking. 

“How can this be a serious programming book?” 
“What’s with all the graphics?” 

“Can I actually learn it this way?” 


And we know what your brain is thinking. 

Your brain craves novelty. It’s always searching, scanning, waiting for 
something unusual. It was built that way, and it helps you stay alive. 

Today, you’re less likely to be a tiger snack. But your brain’s still looking. You 
just never know. 

So what does your brain do with all the routine, ordinary, normal things 
you encounter? Everything it can to stop them from interfering with the 
brain’s real]oh — recording things that matter. It doesn’t bother saving 
the boring things; they never make it past the “this is obviously not 
important” filter. 

How does your brain know what’s important? Suppose you’re out for a day 
hike and a tiger jumps in front of you, what happens inside your head and 
body? 

Neurons fire. Emotions crank up. Chemicals surge. 

And that’s how your brain knows... 

This must be important! Don’t forget it! 

But imagine you’re at home, or in a library. It’s a safe, warm, tiger-free zone 
You’re studying. Getting ready for an exam. Or trying to learn some tough 
technical topic your boss thinks will take a week, ten days at the most. 

Just one problem. Your brain’s trying to do you a big favor. It’s trying 
to make sure that this obviously non-important content doesn’t clutter 
up scarce resources. Resources that are better spent storing the really 
big things. Like tigers. Like the danger of fire. Like how you should 
never again snowboard in shorts. 

And there’s no simple way to tell your brain, “Hey brain, thank you 
very much, but no matter how dull this book is, and how little I’m 
registering on the emotional Richter scale right now, I really do want 
you to keep this stuff around.” 
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Metacognitiovi: thinking about thinking 

If you really want to learn, and you want to learn more quickly and more deeply, 
pay attention to how you pay attention. Think about how you think. Learn how you 
learn. 

Most of us did not take courses on metacognition or learning theory when we were 
growing up. We were expected to learn, but rarely taught to learn. 

But we assume that if you’re holding this book, you really want to learn design 
patterns. And you probably don’t want to spend a lot of time. And you want 
to remember what you read, and be able to apply it. And for that, you’ve got to 
understand it. To get the most from this book, or any book or learning experience, take 
responsibility for your brain. Your brain on this content. 

The trick is to get your brain to see the new material you’re learning as 
Really Important. Crucial to your well-being. As important as a tiger. 

Otherwise, you’re in for a constant battle, with your brain doing its best to 
keep the new content from sticking. 

So how DO you get your brain to think Design 
Patterns are as important as a tiger? 

There’s the slow, tedious way, or the faster, more effective way. The slow 
way is about sheer repetition. You obviously know that you are able 
to learn and remember even the dullest of topics, if you keep pounding on the 
same thing. With enough repetition, your brain says, “This doesn’t feel important to him, 
but he keeps looking at the same thing over and over and over, so I suppose it must be.” 

The faster way is to do anything that increases brain activity^ especially different 
types of brain activity. The things on the previous page are a big part of the solution, 
and they’re all things that have been proven to help your brain work in your favor. For 
example, studies show that putting words within the pictures they describe (as opposed to 
somewhere else in the page, like a caption or in the body text) causes your brain to try to 
makes sense of how the words and picture relate, and this causes more neurons to fire. 
More neurons firing = more chances for your brain to get that this is something worth 
paying attention to, and possibly recording. 

A conversational style helps because people tend to pay more attention when they 
perceive that they’re in a conversation, since they’re expected to follow along and hold up 
their end. The amazing thing is, your brain doesn’t necessarily care that the “conversation” 
is between you and a book! On the other hand, if the writing style is formal and dry, your 
brain perceives it the same way you experience being lectured to while sitting in a roomful 
of passive attendees. No need to stay awake. 

But pictures and conversational style are just the beginning. 
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Here's what WE did: 


We used pictures, because your brain is tuned for visuals, not text. As far as your brain’s 
concerned, a picture really is worth 1024 words. And when text and pictures work together, we 
embedded the text in the pictures because your brain works more effectively when the text is 
within the thing the text refers to, as opposed to in a caption or buried in the text somewhere. 

We used redundancy, saying the same thing in different ways and with different media types, 
and multiple senses^ to increase the chance that the content gets coded into more than one area of 
your brain. 


ONBTO MANY RELATIONSHIP 



We used concepts and pictures in unexpected ways because your brain is tuned for novelty, 
and we used pictures and ideas with at least some emotional content, because your brain is 
tuned to pay attention to the biochemistry of emotions. That which causes you to feel something 
is more likely to be remembered, even if that feeling is nothing more than a little humor, 
surprise^ or interest. 

We used a personalized, conversational style, because your brain is tuned to pay more 
attention when it believes you’re in a conversation than if it thinks you’re passively listening to a 
presentation. Your brain does this even when you’re reading. 





The Patterns Guru 


We included more than 40 activities, because your brain is tuned to learn and remember 
more when you do things than when you read about things. And we made the exercises 
challenging-yet-do-able, because that’s what most people prefer. 

We used multiple learning styles ，becausejow might prefer step-by-step procedures, while 
someone else wants to understand the big picture first, while someone else just wants to see a 
code example. But regardless of your own learning preference, everyone benefits from seeing the 
same content represented in multiple ways. 


BULLET POINT! 




We include content for both sides of your brain, because the more of your brain you 
engage, the more likely you are to learn and remember, and the longer you can stay focused. 
Since working one side of the brain often means giving the other side a chance to rest, you can 
be more productive at learning for a longer period of time. 

And we included stories and exercises that present more than one point of vievo, because 
your brain is tuned to learn more deeply when it’s forced to make evaluations and judgements. 

We included challenges^ with exercises, and by asking questions that don’t always have 
a straight answer, because your brain is tuned to learn and remember when it has to work at 
something. Think about it~~you can’t get your body in shape just by watching people at the gym. 
But we did our best to make sure that when you’re working hard, it’s on the right things. That 
you^re not spending one extra dendrite processing a hard-to-understand example, or 
parsing difficult, jargon-laden, or overly terse text. 

We people. In stories, examples, pictures, etc., because, well, because j ⑽ V a person. And 
your brain pays more attention to people than it does to things. 

We used an 80/20 approach. We assume that if you’re going for a PhD in software design, this 
won’t be your only book. So we don’t talk about every thing. Just the stuff you’ll actually need. 


Puzzles 
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Here's what YOU caw do to bend 
your brain into submission 


So, we did our part. The rest is up to you. These tips are a 
starting point; listen to your brain and figure out what works 
for you and what doesn’t. Try new things. 




it 


Slow down. The more you understand, 
the less you have to memorize. 

Don’t just read. Stop and think. When the 
book asks you a question, don’t just skip to the 
answer. Imagine that someone really is asking 
the question. The more deeply you force your 
brain to think, the better chance you have of 
learning and remembering. 


(7) Talk about it. Out loud. 

Speaking activates a different part of the brain. 

If you’re trying to understand something, or 
increase your chance of remembering it later, say 
it out loud. Better still, try to explain it out loud 
to someone else. You’ll learn more quickly, and 
you might uncover ideas you hadn’t known were 
there when you were reading about it. 


( 2 ) Do the exercises. Write your own notes. 

We put them in, but if we did them for you, 
that would be like having someone else do 
your workouts for you. And don’t just look at 
the exercises. Use a pencil. There’s plenty of 
evidence that physical activity while learning 
can increase the learning. 

(3) Read the “There are No Dumb Questions” 

That means all of them. They’re not optional 
side-bars — they y re part of the core content! 
Don’t skip them. 

(5) Make this the last thing you read before 
bed. Or at least the last challenging thing. 

Part of the learning (especially the transfer to 
long-term memory) happens after you put the 
book down. Your brain needs time on its own, to 
do more processing. If you put in something new 
during that processing-time, some of what you 
just learned will be lost. 

Drink water. Lots of it. 

Your brain works best in a nice bath of fluid. De¬ 
hydration (which can happen before you ever feel 
thirsty) decreases cognitive function. 


(§) Listen to your brain. 

Pay attention to whether your brain is getting 
overloaded. If you find yourself starting to skim the 
surface or forget what you just read, it’s time for a 
break. Once you go past a certain point, you won’t 
learn faster by trying to shove more in, and you 
might even hurt the process. 

(9) Feel something! 

Your brain needs to know that this matters. Get 
involved with the stories. Make up your own cap¬ 
tions for the photos. Groaning over a bad joke is still 
better than feeling nothing at all. 

Design something! 

Apply this to something new you’re designing, or 
refactor an older project. Just do something to get 
some experience beyond the exercises and activities 
in this book. All you need is a pencil and a problem 
to solve... a problem that might benefit from one or 
more design patterns. 
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Read Me 


This is a learning experience, not a reference book. We deliberately stripped out 
everything that might get in the way of learning whatever it is we’re working on at that 

point in the book. And the first time through, you need to begin at the beginning, because 必 a s\^ c，f, —\ 

the book makes assumptions about what you’ve already seen and learned. 


We use simple UML-like diagrams. 

Although there’s a good chance you’ve run across UML, it’s not covered in the book, and 
it’s not a prerequisite for the book. If you’ve never seen UML before, don’t worry, we’ll 
give you a few pointers along the way. So in other words, you won’t have to worry about 
Design Patterns and UML at the same time. Our diagrams are “UML-like” -- while we 
try to be true to UML there are times we bend the rules a bit, usually for our own selfish 
artistic reasons. 


Director 


getMovies 

getOscars() 

getKevinBaconDegrees() 


We don’t cover every single Design Pattern ever created. 

There are a lot of Design Patterns: The original foundational patterns (known as the GoF 
patterns), Sun 5 s J2EE patterns, JSP patterns, architectural patterns, game design patterns 
and Si lot more. But our goal was to make sure the book weighed less than the person 
reading it, so we don’t cover them all here. Our focus is on the core patterns that matter 
from the original GoF patterns, and making sure that you really, truly，deeply understand 
how and when to use them. You will find a brief look at some of the other patterns (the 
ones you’re far less likely to use) in the appendix. In any case, once you’re done with Head 
First Design Patterns, you’ll be able to pick up any pattern catalog and get up to speed 
quickly. 

The activities are NOT optional. 

The exercises and activities are not add-ons; they’re part of the core content of the book. 
Some of them are to help with memory, some for understanding, and some to help you 
apply what you’ve learned. Don 3 t skip the exercises. The crossword puzzles are the 
only things you don’t have to do, but they’re good for giving your brain a chance to think 
about the words from a different context. 


We use the word “composition” in the general OO sense, which is 
more flexible than the strict UML use of “composition”. 

When we say “one object is composed with another object” we mean that they are related 
by a HAS-A relationship. Our use reflects the traditional use of the term and is the one 
used in the GoF text (you’ll learn what that is later). More recently, UML has refined 
this term into several types of composition. If you are an UML expert, you’ll still be able 
to read the book and you should be able to easily map the use of composition to more 
refined terms as you read. 
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The redundancy is intentional and important. 

One distinct difference in a Head First book is that we want you to really get it. And we want 
you to finish the book remembering what you’ve learned. Most reference books don’t have 
retention and recall as a goal, but this book is about learnings so you’ll see some of the same 
concepts come up more than once. 


The code examples are as lean as possible. 


Our readers tell us that it’s frustrating to wade through 200 lines of code looking for the two 
lines they need to understand. Most examples in this book are shown within the smallest 
possible context, so that the part you’re trying to learn is clear and simple. Don’t expect 
all of the code to be robust, or even complete — the examples are written specifically for 
learning, and aren’t always fully-functional. 

In some cases, we haven’t included all of the import statements needed, but we assume that 
if you’re a Java programmer, you know that ArrayList is in java.util, for example. If the 
imports were not part of the normal core J2SE API, we mention it. We’ve also placed all 
the source code on the web so you can download it. You’ll find it at 
http : / / www. headfirst labs . com/books/hfdp/ 

Also, for the sake of focusing on the learning side of the code, we did not put our classes 
into packages (in other words, they’re all in the Java default package). We don’t recommend 
this in the real world, and when you download the code examples from this book, you’ll find 
that all classes are in packages. 


The £ Brain Power’ exercises don’t have answers. 


For some of them, there is no right answer, and for others, part of the learning experience 
of the Brain Power activities is for you to decide if and when your answers are right. In 
some of the Brain Power exercises you will find hints to point you in the right direction. 
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Welcome to 肀 ♦ 
♦ Design Patterns 


Objectville, we’ve just got 


to get into Design Patterns. 


doing them. Soon 


everyone 


we 11 be the hit of Jim and 


Someone has already solved your problems, in this chapter, you’ll leam 
why (and how) you can exploit the wisdom and lessons learned by other developers who’ve 
been down the same design problem road and survived the trip. Before we’re done, we’ll 
look at the use and benefits of design patterns, look at some key 00 design principles, and 
walk through an example of how one pattern works. The best way to use patterns is to load 
your brain with them and then recognize places in your designs and existing applications 
where you can apply them. Instead of code reuse, with patterns you get experience reuse. 


this is a new chapter 
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Sim UDuck 


It started with a simple SimUPuck app 

Joe works for a company that makes a highly successful duck pond 
simulation game, SimUDuck. The game can show a large variety of 
duck species swimming and making quacking sounds. The initial 
designers of the system used standard OO techniques and created 
one Duck superclass from which all other duck types inherit. 


All dudks <^uadk swim, -tKc 〆 ^ 

su^cvdlass takes o( tKc 

Code- 


1 多， 





MallardDuck 


RedheadDuck 

display() { 


display() { 

II looks like a mallard} 


II looks like a redhead} 


sCX 




In the last year, the company has been under increasing pressure 
from competitors. After a week long off-site brainstorming 
session over golf, the company executives think it’s time for a big 
innovation. They need something really impressive to show at the 
upcoming shareholders meeting in Maui next week. 
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Pot wow we need the docks to FLY 



I just need to add a fly() 
method in the Duck class and 
then all the ducks will inherit it. 
Now's my time to really show my 
true 00 genius. 


The executives decided that flying ducks is just what the 
simulator needs to blow away the other duck sim competitors. 
And of course Joe’s manager told them it’ll be no problem 
for Joe to just whip something up in a week. “After all”，said 
Joe’s boss, “he’s an OO programmer... how hard can it be?” 


liVKat >mc want 



you are here ► 
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something went wrong 


Put something went horribly wrong... 


Joe, I’m at the 
shareholders meeting. 

They just gave a demo and there 
were rubber duckies flying around 
the screen. Was this your idea of 
a joke? You might want to spend 
some time on Monster.com... 




What happened? 

Joe failed to notice that not all 
subclasses of Duck should fly. When 
Joe added new behavior to the 
Duck superclass, he was also adding 
behavior that was not appropriate 
for some Duck subclasses. He now 
has flying inanimate objects in the 
SimUDuck program. 

A localized update to the code caused, a non¬ 
local side effect (flying rubber ducks)! 




OK, so there's a slight 
flaw in my design. I 
don’t see why they can’t 
just call it a ''feature". 
It's kind of cute... 






警 


Duck 


quack() 

swim() 

display() 

fiy() 

II OTHER duck-like methods... 

1 


△ 



MallardDuck 


RedheadDuck 

display() { 


display() { 

II looks like a mallard 


II looks like a redhead 

} 


} 


RubberDuck 

quack() { 

II overridden to Squeak 

} 

display() { 

II looks like a rubberduck 


Wkat ke tkougfkt 
was a great use 
of inkeritance 
for tke purpose 
ojf reuse liasn’t 
turned out so well 
vken it comes to 
maintenance. 


to V ^ aW - 
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Joe thinks about iwhcritawce... 




;；Sharpen your pencil 


Which of the following are disadvantages of using inheritance to 
provide Duck behavior? (Choose all that apply.) 


Q A. Code is duplicated across subclasses, 
d B. Runtime behavior changes are difficult, 
[t C. We can’t make ducks dance. 


口 D. Hard to gain knowledge of all duck behaviors. 
Q E. Ducks can’t fly and quack at the same time. 

Q F. Changes can unintentionally affect other ducks. 


you are here ► 


5 







inheritance is not the answer 


How about an interface? 

Joe realized that inheritance probably wasn’t the 
answer, because he just got a memo that says that 
the executives now want to update the product every 
six months (in ways they haven’t yet decided on). Joe 
knows the spec will keep changing and he’ll be forced 
to look at and possibly override flyO and quackO for 
every new Duck subclass that’s ever added to the 
program. ..forever. 

So, he needs a cleaner way to have only some (but not 
all) of the duck types fly or quack. 


I could take the fly() out of the 
Duck superclass, and make a 
Flyable() interface with a fly() 
method. That way, only the ducks that 
are supposed to fly will implement that 
interface and have a fly() method... and 
I might as well make a Quackable, too, 
since not all ducks can quack. 





MallardDuck 


RedheadDuck 


RubberDuck 


DecoyDuck 

display() 


display() 


display() 


display() 

fiy() 


fiy() 


quackQ 



quackQ 


quack() 






What do YOU think about this design? 
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That is, like, the dumbest idea 
you’ve come up with. Can you say, 
''duplicate code ”？ If you thought 
having to override a few methods was bad, 
how are you gonna feel when you need 
to make a little change to the flying 
behavior... in all 48 of the flying 
buck subclasses?! 



What would you do if you were Joe? 

We know that not all of the subclasses should have flying or quacking 
behavior, so inheritance isn’t the right answer. But while having 
the subclasses implement Flyable and/or Quackable solves part of 
the problem (no inappropriately flying rubber ducks), it completely 
destroys code reuse for those behaviors, so it just creates a different 
maintenance nightmare. And of course there might be more than 
one kind of flying behavior even among the ducks that do fly... 

At this point you might be waiting for a Design Pattern to come 
riding in on a white horse and save the day. But what fun would that 
be? No, we’re going to figure out a solution the old-fashioned way — 
by applying good, 00 software design principles. 



you are here ► 
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change is constant 


The owe cowstawt iw software development 

Okay ， what’s the one thing you can always count on in software development? 

No matter where you work, what you’re building, or what language you are programming in, what’s 
the one true constant that will be with you always? 


aomso 

(use a mirror to see the answer) 

No matter how well you design an application, over time an 
application must grow and change or it will die. 


賢考 rpen your pencil 


Lots of things can drive change. List some reasons 
you’ve had to change code in your applications (we put 
in a couple of our own to get you started). 


My dus-tomevs ov usevs dedide -tKcy somc-tK'mj else, ov -tKcy new 


/Vly decided i-b is 50'mj v/i-tK a^o-tKcv database vc^dov i-t is also ^uv-^Kas'mj 

its daia -fv-om a^o-tKcv su^licv -tKa-t uses a daia -fovma-t- 


8 


Chapter 1 





intro to Design Patterns 


Zeroing in on the problem... 


So we know using inheritance hasn’t worked out very well, since 
the duck behavior keeps changing across the subclasses, and it’s 
not appropriate for all subclasses to have those behaviors. The 
Flyable and Quackable interface sounded promising at first — only 
ducks that really do fly will be Flyable, etc. — except Java interfaces 
have no implementation code, so no code reuse. And that means 
that whenever you need to modify a behavior, you’re forced to 
track down and change it in all the different subclasses where that 
behavior is defined, probably introducing new bugs along the way! 

Luckily, there’s a design principle for just this situation. 



r Owv- -fivst many desi 沪 

、 yv'mdifles. IA/ell 彳 end «-ove 七 i"e 
on these thvwojtiowt tV>e book. 

In other words, if you’ve got some aspect of your code that is 
changing, say with every new requirement, then you know you’ve 
got a behavior that needs to be pulled out and separated from all 
the stuff that doesn’t change. 

Here’s another way to think about this principle: take the parts 
that vary and encapsulate them，so that later you can 
alter or extend the parts that vary without affecting 
those that don’t. 

As simple as this concept is, it forms the basis for almost every 
design pattern. All patterns provide a way to let some part of a system 
vary independently of all other parts. 

Okay, time to pull the duck behavior out of the Duck classes! 


Take wkat varies anct 
” encapsulate” it so it won^ 
aHect tke rest oi your code. 


Tlie result? Fewer 
unintenctect consequences 
Irom cocte ckangfes and more 
ilexitility in your systems! 


you are here 
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pull out what varies 


Separating what changes from what stays the same 

Where do we start? As far as we can tell, other than the problems with flyO and quackO, the Duck 
class is working well and there are no other parts of it that appear to vary or change frequently. 

So, other than a few slight changes, we’re going to pretty much leave the Duck class alone. 

Now, to separate the “parts that change from those that stay the same’’，we are going to create two 
sets of classes (totally apart from Duck), one for fly and one for quack. Each set of classes will hold 
all the implementations of their respective behavior. For instance, we might have one class that 
implements quacking, another that implements squeaking, and another that implements silence. 


We know that fly() and quack() are the parts of the 
Duck class that vary across ducks. 

To separate these behaviors from the Duck class, we’ll 
pull both methods out of the Duck class and create a 
new set of classes to represent each behavior. 
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designing the Puck behaviors 


So how are we going to design the set of classes that 
implement the fly and quack behaviors? 

We’d like to keep things flexible; after all, it was the inflexibility in 
the duck behaviors that got us into trouble in the first place. And we 
know that we want to assign behaviors to the instances of Duck. For 
example, we might want to instantiate a new MallardDuck instance 
and initialize it with a specific type of flying behavior. And while 
we’re there, why not make sure that we can change the behavior of 
a duck dynamically? In other words, we should include behavior 
setter methods in the Duck classes so that we can, say, change the 
MallardDuck’s flying behavior at runtime. 

Given these goals, let’s look at our second design principle: 



We’ll use an interface to represent each behavior — for instance, 
FlyBehavior and QuackBehavior — and each implementation of a 
behavior will implement one of those interfaces. 

So this time it won’t be the Duck classes that will implement the 
flying and quacking interfaces. Instead, we’ll make a set of classes 
whose entire reason for living is to represent a behavior (for example, 
“squeaking”)，and it’s the behavior class, rather than the Duck class, 
that will implement the behavior interface. 

This is in contrast to the way we were doing things before, where 
a behavior either came from a concrete implementation in the 
superclass Duck, or by providing a specialized implementation in the 
subclass itself. In both cases we were relying on an implementation. We 
were locked into using that specific implementation and there was no 
room for changing out the behavior (other than writing more code). 

With our new design, the Duck subclasses will use a behavior 
represented by an interface (FlyBehavior and QuackBehavior), so that 
the actual implementation of the behavior (in other words, the specific 
concrete behavior coded in the class that implements the FlyBehavior 
or QuackBehavior) won’t be locked into the Duck subclass. 


From now on, tke Duck 
tekaviors will live in a 
separate class—a class tkat 
implements a particular 
tekavior interface. 


Tkat way, tke Duck classes 
won’t neect to know any oi 
tke implementation details 
: tor tkeir own tekaviors. 


«interface» 

FlyBehavior 

m 


: N K 


FlyWithWings 

FlyNoWay 

fly(){ 

II implements duck flying 

} 

fly(){ 

II do nothing - can’t fly! 

} 



you are here ► 
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program to an interface 



I don't see why you have to 
use an interface for Fly Behavior 
You can do the same thing with an 
abstract superclass. Isn't the 
whole point to use polymorphism? 






“Program to an interface" really means 
“Program to a supertype ■” 

The word interface is overloaded here. There’s the concept of 
interface, but there’s also the Java construct interface. You 
can program to an interface, without having to actually use a 
Java interface. The point is to exploit polymorphism by 
programming to a supertype so that the actual runtime object 
isn’t locked into the code. And we could rephrase “program to 
a supertype” as “the declared type of the variables should be a 
supertype, usually an abstract class or interface, so that the objects 
assigned to those variables can be of any concrete implementation 
of the supertype, which means the class declaring them doesn’t 
have to know about the actual object types!” 

This is probably old news to you, but just to make sure we’re 
all saying the same thing, here’s a simple example of using a 
polymorphic type - imagine an abstract class Animal, with two 
concrete implementations, Dog and Cat. 

Programming to an implementation would be: 


Dog d = new Dog() 
d.bark(); 


pedav-m 9 variable { 'd" as b/ ?e t>oo 

7 dohdlre \ e of 心 iwl? 

+ovd« w io dode i 0 a io^ e i e 
irwplcrwchtatioh. 



But programming to an interface/supertype would be: 

, n / \ k^ow ii S a Doa, but 

Animal animal = new Dog () ; Ul - ^ , 

^ wc dan how use the ahi^al 

animal. makeSoundO ; *-e-fe«hde po 卜 ovphidally. 

Even better, rather than hard-coding the instantiation of the 
subtype (like new DogO) into the code, assign the concrete 
implementation object at runtime: 


a = getAnimal() 
a.makeSound(); 


^ mhT ihc adtual 
ah.mal subtype is... all wc dav-c aboui 

，S , ^ how *to V-CSPohd to 

r»»akcSouhdO. 
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Implementing the Puck Pehaviors 


Here we have the two interfaces, FlyBehavior and QuackBehavior along with 
the corresponding classes that implement each concrete behavior: 



. d// i 


/ 

fly ^ 


^bUals re ak. 峽 

y>0 SOWT>d a 七 all. 


With this design, other types of objects can 
reuse our fly and quack behaviors because 
these behaviors are no longer hidden away 
in our Duck classes! 

And we can add new behaviors without 
modifying any of our existing behavior 
classes or touching any of the Duck classes 
that use flying behaviors. 
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behavior in a class 


tjierei^renp 

)umb Quest 


ipns 


Do I always have to implement my application first, see 
where things are changing, and then go back and separate & 
encapsulate those things? 


It feels a little weird to have a class that’s just a 
behavior. Aren’t classes supposed to represent things? Aren’t 
classes supposed to have both state AND behavior? 


A. 

Not always; often when you are designing an application, 
you anticipate those areas that are going to vary and then go ahead 
and build the flexibility to deal with it into your code. You’ll find 
that the principles and patterns can be applied at any stage of the 
development lifecycle. 


Should we make Duck an interface too? 


A. 

-Ml- In an 00 system, yes, classes represent things that 
generally have both state (instance variables) and methods. And in 
this case, the thing happens to be a behavior. But even a behavior 
can still have state and methods; a flying behavior might have 
instance variables representing the attributes for the flying (wing 
beats per minute, max altitude and speed, etc.) behavior. 


A. 

Jr \* Not in this case. As you’ll see once we’ve got everything 
hooked together, we do benefit by having Duck not be an interface 
and having specific ducks, like MallardDuck, inherit common 
properties and methods. Now that we’ve removed what varies from 
the Duck inheritance, we get the benefits of this structure without 
the problems. 


^ Sharpen your pencil 


❶ 


Using our new design, what would you do if you needed to 
add rocket-powered flying to the SimUDuck app? 


❾ 


Can you think of a class that might want to use the Quack 
behavior that isn’t a duck? 


.(spimos ^onp sa^ui 3 DiA 9 p 

T2) U 它 3 >[Onp 12 c 3^dui^X9 3UQ fe 

•9DBJJ91UI 

JOpV 它 ipgAljJ 3ip SJU9UI3{duiI 
ss 它 p ^ 9 ^ 9 j 3 (j 
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Integrating the Puck Pchavior 

The key is that a Duck will now delegate its flying 
and quacking behavior，instead of using quacking and 
flying methods defined in the Duck class (or subclass). 

Here’s how: 

First we’ll add two instance variables to the Duck class called flyBehavior and 
quackBehavior, that are declared as the interface type (not a concrete class implementation 
type). Each duck object will set these variables polymorphically to reference the specific 
behavior type it would like at runtime (FlyWith Wings ， Squeak, etc.). 

We’ll also remove the flyO and quack() methods from the Duck class (and any subclasses) 
because we’ve moved this behavior out into the FlyBehavior and QuackBehavior classes. 

We’ll replace flyO and quackO in the Duck class with two similar methods, called 
performFlyQ and performQuackQ ； you’ll see how they work next. 


TKc bcV^aviov- vaviablcs av-c 
dedaved as bAavior 

INTERFACE 

methods v-cylatc 
arvd 


vav-iables hold a vc-fcv-cndc io 
a spedi-fid bchaviov* a 七 vuntime- 


FlyBehavior flyBehavior 
QuackBehavior quackBehavior 



performQuack() 

swim() 

display() 

performFlyf) 

II OTHER duck-like methods. 


Now we implement performQuack() : 

public class Duck { 

QuackBehavior quackBehavior; sr 
// more 


public void performQuack() 
quackBehavior.quack(); 


C io so^etWmo^ 

⑼ r 工一 


} 

Pretty simple, huh? To perform the quack, a Duck just allows the object that 
is referenced by quackBehavior to quack for it. 

In this part of the code we don’t care what kind of object it is, all we care 
about is that it knows how to quackQ! 
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integrating duck behavior 


More Iwtegratiow... 


Okay, time to worry about how the flyBehavior and 
quackBehavior instance variables are set. Let’s take a look at 
the MallardDuck class: 


public class MallardDuck extends Duck { 


public MallardDuck () { 

quackBehavior = new Quack(); 
flyBehavior = new FlyWithWings () 

} 


Rcmcrwbcv, MallavdPu^k mKcv-its tKc <\uatk- 
Bc^aviov and -flYBc^aviov ms-tandc vaviablcs 
-fvorw dlass Dudk. 


., s —d, 

M .A uses^W't^as^ 

p^3cV>av'»ov 


public void display() { 

System.out .println (' 、工 ' m a real Mallard duck"); 

} 


So MallardDuck^ quack is a real live duck quack, not a squeak and 
not a mute quack. So what happens here? When a MallardDuck 
is instantiated, its constructor initializes the MallardDuck^ inherited 
quackBehavior instance variable to a new instance of type Quack (a 
QuackBehavior concrete implementation class). 

And the same is true for the duck’s flying behavior — the MallardDuck’s 
constructor initializes the flyBehavior instance variable with an instance 
of type FlyWithWings (a FlyBehavior concrete implementation class). 
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Wait a second, didn’t you 
say we should NOT program to an 
implementation? But what are we doing 
in that constructor? Were making a 
new instance of a concrete Quack 
implementation class! 


Good catch, that’s exactly what we’re doing... 
for now. 

Later in the book we’ll have more patterns in 
our toolbox that can help us fix it. 

Still, notice that while we are setting the 
behaviors to concrete classes (by instantiating 
a behavior class like Quack or FlyWithWings 
and assigning it to our behavior reference 
variable), we could easily change that at 
runtime. 

So, we still have a lot of flexibility here, 
but we’re doing a poor job of initializing 
the instance variables in a flexible way. But 
think about it, since the quackBehavior 
instance variable is an interface type, we 
could (through the magic of polymorphism) 
dynamically assign a different QuackBehavior 
implementation class at runtime. 


Take a moment and think about how you 
would implement a duck so that its behavior 
could change at runtime. (You’ll see the code 
that does this a few pages from now.) 


you are here 
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Testing the Puck code 


❹ Type and compile the Duck class below (Duck.java)，and the 
MallardDuck class from two pages back (MallardDuck.java). 


public abstract class Duck { 


FlyBehavior flyBehavior; 
QuackBehavior quackBehavior; 



public Duck() { 


p e da« 七糾。 代 W 说广 

^\|| a«tk subtlasses Cm -tv,e same 

^>atkay) 


public abstract void display(); 


public void performFly() { 

flyBehavior. fly () ; ^ - 


public void performQuack() 
quackBehavior.quack(); 


Pdcjaic -to -tKc bcKaviov dlass. 



public void swim() { 

System, out .println (''All ducks float, even decoys l ff ); 


❺ Type and compile the FlyBehavior interface (FlyBehavior.java) and 
the two behavior implementation classes (FlyWithWings.java and 
FlyNoWay.java). 


public interface FlyBehavior { 
public void fly (); 


TKc m-tev-fade all 
bcV^aviov classes 


public class FlyWithWings implements FlyBehavior 
public void fly () { 

System, out .println flying! !〃）； 




or\ 


public class FlyNoWay implements FlyBehavior { 
public void fly () { 

System, out .println (''I can’t fly"); 
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Testing the Puck code continued... 

❾ Type and compile the QuackBehavior interface 

(QuackBehavior.java) and the three behavior implementation 
classes (Quack.java, MuteQuack.java, and Sqeak.java). 

public interface QuackBehavior { 
public void quack(); 

} 


public class Quack implements QuackBehavior { 
public void quack() { 

System, out .println (''Quack"); 



public class MuteQuack implements QuackBehavior { 
public void quack() { 

System.out .println (''« Silence >>〃）； 



public class Squeak implements QuackBehavior { 
public void quack() { 

System, out .println (''Squeak ’’）； 

} 


❹ Type and compile the test class 
(MiniDuckSimulator.java). 


public class MiniDuckSimulator { 

public static void main(String[] args) 
Duck mallard = new MallardDuck(); 
mallard.performQuack() 
mallard.performFly(); 

} 

} 


O Run the code! 


I File Edit Window Help Yadayadayada 


% java MiniDuckSimulator 



Tu . ..ju 4-v.c Mallav-aP^ ，s 

一 如一， '加 ks 
— 。』 7()"'⑽. 




Quack 


flying! 
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ducks with dynamic behavior 


Setting behavior dynamically 

What a shame to have all this dynamic talent built into our ducks and not be using 
it! Imagine you want to set the duck’s behavior type through a setter method on the 
duck subclass, rather than by instantiating it in the duck’s constructor. 

Q Add two new methods to the Duck class: 


public void setFlyBehavior(FlyBehavior fb) { 
flyBehavior = fb; 


public void setQuackBehavior(QuackBehavior qb) 
quackBehavior = qb; 



We can call these metho^S-anytime we want to change the 
behavior of a duck^n the fly.) 


_ Duck _ 

FlyBehavior flyBehavior; 
QuackBehavior quackBehavior; 


swim() 

displayf) 

performQuack() 

perform Fly() 

setFlyBehavior() 

setQuackBehavior() 

II OTHER duck-like methods... 


edltor ^ote: gratuitous pun - fix 


❺ Make a new Duck type (ModelDuck.java). 


public class ModelDuck extends Duck { 
public ModelDuck() { 

flyBehavior = new FlyNoWay () ; 
quackBehavior = new Quack(); 




} 


public void display() { 

System, out .println (''I'm a model duck"); 


❺ 


Make a new FlyBehavior type 
(FlyRocketPowered.java). 



T^a-t's okay, v/cVc dvcaimg a 
vodkrt bc^aviov- 


public class FlyRocketPowered implements FlyBehavior { 
public void fly () { 

System, out .print In flying with a rocket!"); 

} 


/ 
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Q Change the test class (MiniDuckSimulator.java), add the 
ModelDuck, and make the ModelDuck rocket-enabled. 


bc-fovc 


public class MiniDucksimulator { 

public static void main(String[] args) 
Duck mallard = new MallardDuck(); 
mallard.performQuack(); 
mallard.performFly(); 

Duck model = new ModelDuck(); 
model.performFly() / 


O 





model.setFlyBehavior(new FlyRocketPowered()) 
model.performFly() / 



di 山“ 1 心心 


File Edit Window Help Yabadabadoo 


% java MiniDuckSimulator 
Quack 

I'm flying! ! 

I can^ t fly 

I'm flying with a rocket 


丁“山卿^ If 

Mo 秦 

invokes ^ -od e rs i»hm-t e d 

beh fr seiie ^ -eihod, a«d...voila/ The 

r de，sudd , eh, y 

+ly … 3 ^apabiliiy/ 




a-f-tcv 


To ckangfe a duck’s 
teliavior at runtime, just 
call tke ducks setter 
metkoct for tkat tekavior. 


you are here ► 
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the big picture 


The Pig Picture ow encapsulated behaviors 

Okay，now that we’ve done the deep dive on the 
duck simulator design, ifs time to come back up 
for air and take a look at the big picture. 

Below is the entire reworked class structure. We have everything you’d expect: 
ducks extending Duck, fly behaviors implementing FlyBehavior and quack 
behaviors implementing QuackBehavior. 

Notice also that we’ve started to describe things a little differently. Instead 
of thinking of the duck behaviors as a set of behaviors, we’ll start thinking of 
them as a family of algorithms. Think about it: in the SimUDuck design, the 
algorithms represent things a duck would do (different ways of quacking or 
flying), but we could just as easily use the same techniques for a set of classes 
that implement the ways to compute state sales tax by different states. 

Pay careful attention to the relationships between the classes. In fact, grab 
your pen and write the appropriate relationship (IS-A, HAS-A and 
IMPLEMENTS) on each arrow in the class diagram. 
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HAS-A caw be better thaw 1S-A 

The HAS-A relationship is an interesting one: each duck 
has a FlyBehavior and a QuackBehavior to which it 
delegates flying and quacking. 


When you put two classes together like this you’re using 
composition. Instead of inheriting their behavior, the 
ducks get their behavior by being composed with the right 
behavior object. 

This is an important technique; in fact, we’ve been using 
our third design principle: 



As you’ve seen, creating systems using composition gives you 
a lot more flexibility. Not only does it let you encapsulate 
a family of algorithms into their own set of classes, but it 
also lets you change behavior at runtime as long as 
the object you’re composing with implements the correct 
behavior interface. 

Composition is used in many design patterns and you’ll 
see a lot more about its advantages and disadvantages 
throughout the book. 





A duck call is a device that hunters use to mimic the 
calls (quacks) of ducks. How would you implement your 
own duck call that does not inherit from the Duck class? 



Master and Student 

Master: Grasshopper ， 
tell me what you have 
learned of the Object- 
Oriented ways. 


Student: Master, I have learned that 
the promise of the object-oriented way 
is reuse. 


Master: Grasshopper ， continue... 

Student: Master, through inheritance 
all good things may be reused and 
so we will come to drastically cut 
development time like we swiftly cut 
bamboo in the woods. 


Master: Grasshopper, is more 
time spent on code before or after 
development is complete? 

Student: The answer is after, 

Master. We always spend more time 
maintaining and changing software 
than initial development. 

Master: So Grasshopper, should effort 
go into reuse above maintaintability 
and extensibility? 

Student: Master，I believe that there is 
truth in this. 


Master: I can see that you still have 
much to learn. I would like for you to 
go and meditate on inheritance further. 
As you } ve seen, inheritance has its 
problems, and there are other ways of 
achieving reuse. 


you are here 
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the strategy pattern 


Speaking of design Patterns... 


Congratulations on 
your first pattern! 

AU 


You just applied your first design pattern — the 
STRATEGY pattern. That’s right, you used the 
Strategy Pattern to rework the SimUDuck app. 

Thanks to this pattern, the simulator is ready for any 
changes those execs might cook up on their next 
business trip to Vegas. 

Now that we’ve made you take the long road to apply it, 
here’s the formal definition of this pattern: 


The Strategy Pattern defines a family of algorithms, 
encapsulates each one, and makes them interchangeable. 
Strategy lets the algorithm vary independently from 
clients that use it. 
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Below you’ll find a mess of classes and interfaces for an action adventure game. You’ll 
find classes for game characters along with classes for weapon behaviors the characters 
can use in the game. Each character can make use of one weapon at a time, but can 
change weapons at any time during the game. Your job is to sort it all out... 

(Answers are at the end of the chapter.) 


Your task: 

Arrange the classes. 

Identify one abstract class, one interface and eight classes. 
Draw arrows between classes. 

a. Draw this kind of arrow for inheritance (“extends”). ■ 

b. Draw this kind of arrow for interface (“implements”). 

c. Draw this kind of arrow for ct HAS-A , .- - ^ 

Put the method setWeaponQ into the right class. 



you are here ► 25 






diner talk 


Overheard at the local diwi 


Alice 


I need a Cream cheese 
with jelly on white bread, a 
chocolate soda with vanilla ice cream, a 
grilled cheese sandwich with bacon, a tuna 
fish salad on toast, a banana split with 
ice cream & sliced bananas and a coffee 
with a cream and two sugars,... oh, 
and put a hamburger on the grill! 


Flo 

〆 - 

Give me a C.J. 

White, a black & white, a 
Jack Benny, a radio, a house 
boat, a coffee regular and 
burn one! 





What’s the difference between these two orders? Not a thing! They’re both 
the same order, except Alice is using twice the number of words and trying the 
patience of a grumpy short order cook. 

What’s Flo got that Alice doesn’t? A shared vocabulary with the short order 
cook. Not only is it easier to communicate with the cook, but it gives the cook less 
to remember because he’s got all the diner patterns in his head. 

Design Patterns give you a shared vocabulary with other developers. Once you’ve 
got the vocabulary you can more easily communicate with other developers and 
inspire those who don’t know patterns to start learning them. It also elevates your 
thinking about architectures by letting you think at the pattern level, not the 
nitty gritty object level. 
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Overheard iw the next cubicle... 


Can you think of other shared vocabularies 
that are used beyond 00 design and diner 
talk? (Hint: how about auto mechanics, 
carpenters, gourmet chefs, air traffic control) 
What qualities are communicated along with 
the lingo? 

Can you think of aspects of 00 design 
that get communicated along with pattern 
names? What qualities get communicated 
along with the name “Strategy Pattern ”？ 




you are here ► 
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shared vocabulary 


The power of a shared pattern vocabulary 

When you communicate using patterns you 
are doing more than just sharing LINGO. 


Shared pattern vocabularies are POWERFUL. 

When you communicate with another developer or your 
team using patterns, you are communicating not just a 
pattern name but a whole set of qualities, characteristics 
and constraints that the pattern represents. 

Patterns allow you to say more with less. When 
you use a pattern in a description, other developers quickly 
know precisely the design you have in mind. 


Ufvvx to 


Talking at the pattern level allows you to stay 66 in 
the design” longer. Talking about software systems using 
patterns allows you to keep the discussion at the design 
level, without having to dive down to the nitty gritty details 
of implementing objects and classes. 



Shared vocabularies can turbo charge your 
development team. A team well versed in design 
patterns can move more quickly with less room for 
misunderstanding. 


/\ s vyouv -team to desi5« 

ideas a«d e 平一 te 桜咖 

t0 7 


Shared vocabularies encourage more junior 
developers to get up to speed. Junior developers look 
up to experienced developers. When senior developers 
make use of design patterns, junior developers also become 
motivated to learn them. Build a community of pattern 
users at your organization. 


TKmk abou-t s-tav-tmg a fattens s-tudy 
you? at youv- ov-gahiz^iio^ maybe you 
tav\ cvcr\ jet \>a«d v/Wilc youVc leav^ - 

叫 …；） 
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Vouv Code , … 广 

and .—"roved f 
des .， ？3咖吣. 


How do I use Pesigw Patterns? 

We’ve all used off-the-shelf libraries and frameworks. We take them, write some code against their APIs, 
compile them into our programs, and benefit from a lot of code someone else has written. Think about 
the Java APIs and all the functionality they give you: network, GUI, IO, etc. Libraries and frameworks go 
a long way towards a development model where we can just pick and choose components and plug them 
right in. But... they don’t help us structure our own applications in ways that are easier to understand, more 
maintainable and flexible. That’s where Design Patterns come in. 

Design patterns don’t go directly into your code, they first go into your BRAIN. Once you’ve loaded your 
brain with a good working knowledge of patterns, you can then start to apply them to your new designs, 
and rework your old code when you find it’s degrading into an inflexible mess of jungle spaghetti code. 


Duni^t^uestiPns 


If design patterns are so great, 
why can’t someone build a library of 
them so I don’t have to? 

A- 

厂 Design patterns are higher level 
than libraries. Design patterns tell us 
how to structure classes and objects to 
solve certain problems and it is our job to 
adapt those designs to fit our particular 
application. 


Aren’t libraries and frameworks 
also design patterns? 

A- 

Frameworks and libraries are not 
design patterns; they provide specific 
implementations that we link into our 
code. Sometimes, however, libraries and 
frameworks make use of design patterns 
in their implementations. That’s great, 
because once you understand design 
patterns, you’ll more quickly 


understand APIs that are structured 
around design patterns. 

So, there are no libraries of 
design patterns? 

A- 

No, but you will learn later about 
pattern catalogs with lists of patterns that 
you can apply to your applications. 




you are here ► 
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why design patterns? 



Skeptical Pevdoper 



Friewdly 
Patterns froro 


Developer: Okay, hmm, but isn’t this all just good object-oriented design; I mean 
as long as I follow encapsulation and I know about abstraction, inheritance, and 
polymorphism, do I really need to think about Design Patterns? Isn't it pretty 
straightforward? Isn't this why I took all those 00 courses? I think Design 
Patterns are useful for people who don’t know good 00 design. 

Guru: Ah, this is one of the true misunderstandings of object-oriented 
development ： that by knowing the 00 basics we are automatically going to be good at 
building flexible, reusable, and maintainable systems. 

Developer: No? 


Guru: No. As it turns out, constructing 00 systems that have these properties is 
not always obvious and has been discovered only through hard work. 

Developer: I think I’m starting to get it. These, sometimes non-obvious, ways of 
constructing object-oriented systems have been collected... 

Guru: ...yes, into a set of patterns called Design Patterns. 

Developer: So, by knowing patterns, I can skip the hard work and jump straight to 
designs that always work? 


Guru: Yes, to an extent, but remember, design is an art. There will always be 
tradeoffs. But, if you follow well thought-out and time-tested design patterns, you’ll 
be way ahead. 

Developer: What do I do if I cant find a pattern? 
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Remember, knowing 
concepts like abstraction, 
inheritance, and polymorphism do 
not make you a good object oriented 
designer. A design guru thinks about 
how to create flexible designs that 
are maintainable and that can 
cope with change. 



Guru: There are some object oriented-principles that 
underlie the patterns, and knowing these will help you 
to cope when you can’t find a pattern that matches your 
problem. 

Developer: Principles? You mean beyond abstraction, 
encapsulation, and... 

Guru: Yes, one of the secrets to creating maintainable 
00 systems is thinking about how they might change in the 
future and these principles address those issues. 


you are here 
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your design toolbox 


I 、二、 " 、 

I ferTools for your design toolbox 

You’ve nearly made it through the first 
chapter! You’ve already put a few tools 
in your OO toolbox; let’s make a list of 
them before we move on to Chapter 2. 


00 衫 as'ts 

AWtra 如*' 

“ta—at'。*' 
p 命 〆? Wsn> 

00 

^avov co^ oi '^' or ' 

r 二。， ， 


u, e 00 ^ 

% 二二，二 
_ 1 Vxovl , 

yjovVs. 1 '' oVA t 'i 0 ^ w、 s 

j a>i a rC . 




00 pattern 

,f-W d aV ^ Ws ， 

cWi^ - deWS a a td i s 枷 "： +W 


TV^VOU^OU't 七 ^ 

book ^Wmk about 
hov/ ^attev-rvs vcly 
00 basics av\d 
^v'md.i^lcs- 


0 r\t Ao^i 


■bo 5 °- 


& 


r BULLET POIN 


Knowing the 00 basics 
does not make you a good 
00 designer. 

Good 00 designs are 
reusable, extensible and 
maintainable. 

Patterns show you how to 
build systems with good 
00 design qualities. 

Patterns are proven object- 
oriented experience. 

Patterns don’t give you 
code, they give you 
general solutions to design 
problems. You apply them 
to your specific application. 

Patterns aren’t invented, 
they are discovered. 

Most patterns and 
principles address issues of 
change in software. 

Most patterns allow some 
part of a system to vary 
independently of all other 
parts. 

We often try to take what 
varies in a system and 
encapsulate it. 

Patterns provide a 
shared language that can 
maximize the value of your 
communication with other 
developers. 
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Let’s give your right brain something to do. 

It’s your standard crossword; all of the solution words 
are from this chapter. 



Across 

2._what varies 

4. Design patterns_ 

6. Java 10, Networking, Sound 

9. Rubberducks make a 

13. Bartender thought they were called 

15. Program to this, not an implementation 

17. Patterns go into your_ 

18. Learn from the other guy's 

19. Development constant 

20. Patterns give us a shared_ 


Down 

I. Patterns_in many applications 

3. Favor over inheritance 

5. Dan was thrilled with this pattern 

7. Most patterns follow from 00_ 

8. Not your own 

10. High level libraries 

II. Joe's favorite drink 

12. Pattern that fixed the simulator 

13. Duck that can't quack 

14. Grilled cheese with bacon 

16. Duck demo was located where 


you are here ► 
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design puzzle solution 



Design Puzzle Solution 


Character is the abstract class for all the other characters (King, Queen, 
Knight and Troll) while Weapon is an interface that all weapons 
implement. So all actual characters and weapons are concrete classes. 

To switch weapons, each character calls the setWeaponO method, which 
is defined in the Character superclass. During a fight the useWeaponO 
method is called on the current weapon set for a given character to inflict 
great bodily damage on another character. 


abs-tvad-t 
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Solutions 



Which of the following are disadvantages of using subclassing to provide specific 
Duck behavior? (Choose all that apply.) 


aT 

a/ 

□ 


A. Code is duplicated across subclasses. 

B. Runtime behavior changes are difficult. 

C. We can’t make duck’s dance. 


10^C. Hard to gain knowledge of all duck behaviors. 
Q D. Ducks can’t fly and quack at the same time. 

E. Changes can unintentionally affect other ducks. 
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cj^rpen your pencil 


What are some factors that drive change in your applications? You might 
have a very different list, but here’s a few of ours. Look familiar? 


/V|y dus-tomcv-s ov- uscv-s decide -tKcy v/a^-t somc-tK'mg else, ov- -tKcy >wa»vt 

My tom^y\y decided ii is v/i-tK ano-tKcv daiabase vc^dov and ii is also puv-^Kas'mj i-ts daia 
•fvom a^o-tKcv- su^licv -tKat uses a di-f-fcv-cn-t daia -fovma-t- 

iVdl, -tcdKholojy dKar»ys v/^vc 30 七 七 。 update ouv todt -to make use of fv-otodols. 

leaded cr»ougK buildmg ouv sys-tcrw -tKa-t v/e’d like -to jo badk do -tK'mgs a little bc-ttcv- 
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2 the O^serVer r^tt^rn 


w 


Keeping yot/r ♦ ^ 

Objects in the know 



Don’t miss out when something interesting happens! we’ve got a 

pattern that keeps your objects in the know when something they might care about happens. 
Objects can even decide at runtime whether they want to be kept informed. The Observer 
Pattern is one of the most heavily used patterns in the JDK, and it’s incredibly useful. Before 
we’re done, we’ll also look at one to many relationships and loose coupling (yeah, that’s right, 
we said coupling). With Observer, you’ll be the life of the Patterns Party. 


this is a new chapter 
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weather monitoring station 


Congratulations! 

Your team has just won the contract to build 
Weather-O-Rama ， Inc.’s next generation, 
Internet-based Weather Monitoring Station. 


Weat her- 0 -Ba«'»-' nC - 

r:: 二― 


_ S^entof^K 

lected to build our & 

Internet-bas baS edonour P at ^ 咖 邮 onS 

The rather 二 〆 s : 口二) ，， d ， 

WeatherData 0 =匕孙 一 barometnc P provideS 祕 
(temp erature ， 乜 application that 1 statistics an 

fo^ou to create 邱 : 工 邮邮， 

Say < 二?一 一 = 二： 

siw ple foreca^^ ostrece ntmeasurem _ Q _ 

object acquit weather statl °^ velop ers can 

⑽⑽，:二 2 二卿，二一 

Ra ma wants to 二 _ displays 一 P 

write their o p \y that A^'- . s m0 deV. once 

Ukeforyoutosupp &vea gre at buSin p C " fo r each 

: r 二 Br 工口一 ^ 

We look forward to seemg^ 


Sincerely, 



CEO 


p S v/e are oveimg, 


source files to you. 
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the observer pattern 


The Weather Monitoring application overview 


The three players in the system are the weather station (the physical device that 
acquires the actual weather data), the WeatherData object (that tracks the data coming 
from the Weather Station and updates the displays), and the display that shows users 
the current weather conditions. 


Humidity 
sensor device 


Temperature 
sensor device 


O … to 姊⑽ 





\s oy\t « 
and a \ 


pulls data 


displays 



Weather Station 


WeatherData 

object 



Display device 


Pressure 
sensor device 


Weather-O-Rama provides 


What we implement 


The WeatherData object knows how to talk to the physical Weather Station, to get 
updated data. The WeatherData object then updates its displays for the three different 
display elements: Current Conditions (shows temperature, humidity, and pressure), 
Weather Statistics, and a simple forecast. 

Our job, if we choose to accept it, is to create an app that 
uses the WeatherData object to update three displays for 
current conditions, weather stats，and a forecast. 


you are here ► 
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weather data class 


Unpacking the WeatherPata class 


As promised, the next morning the WeatherData source files arrive. 
Peeking inside the code, things look pretty straightforward: 





ior»s is jus-fe 
S^V*CChS. 


WeatherData.java 



Our job is to implement measurementsChanged() 
so that it updates the three displays for current 
conditions, weather stats, and forecast. 


Display device 
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the observer pattern 


What do we know so far? 



The spec from Weather-O-Rama wasn’t all that clear, but we have to 
figure out what we need to do. So, what do we know so far? 


^ The WeatherData class has getter methods for three 
measurement values: temperature, humidity and 
barometric pressure. 


getTemperature() 
getHumidity() 
getPressure() 


0 The measurementsChanged() method is called any 
time new weather measurement data is available. (We 
don’t know or care how this method is called; we just 
know that it is.) 


0 We need to implement three display elements that 
use the weather data: a current conditions display, a 
statistics display and a forecast display. These displays 
must be updated each time WeatherData has new 
measurements. 


measurementsChanged() 



o o 00 



Display One 



Stats 

Avg. temp: 62° 
Min. temp: 50° 
Max. temp: 78°l 


o o oo 



Display Two 



Display Three 


0 The system must be expandable — other developers 
can create new custom display elements and users 
can add or remove as many display elements as they 
want to the application. Currently, we know about 
only the initial three display types (current conditions, 
statistics and forecast). 



o o 0O 



Future displays 


you are here 
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first try with the weather station 


Taking a first misguided SWAfr at 
the Weather Station 


Here’s a first implementation possibility — we’ll take the hint from the Weather-O- 
Rama developers and add our code to the measurementsChangedO method: 


public class WeatherData { 

// instance variable declarations 


} 


public void measurementsChangedO { 


float temp = getTemperature (); 
float humidity = getHumidity () 
float pressure = getPressure (); 


^v-ab tKc most mcasuv-crwcts 

by dallmj WcatKcirPa-ta's jettev- 
wrtV>ods (alvcady 


Ko>w update 
i\\t displays.. 


currentConditionsDisplay•update(temp, humidity, pressure) 
statisticsDisplay.update(temp, humidity, pressure); 
forecastDisplay.update(temp, humidity, pressure); 

} 、 

'Call ca^K display 

// other WeatherData methods here ；/ .. / zo 

pd f c，ts d,s P la y, passim ii iKc 
most 


terpen your pencil 


Based on our first implementation, which of the following apply? 
(Choose all that apply.) 


[I A. We are coding to concrete 

implementations, not interfaces. 

d B. For every new display element we need 
to alter code. 

Q C. We have no way to add (or remove) 
display elements at run time. 


Q D. The display elements don’t implement a 
common interface. 

d E. We haven’t encapsulated the part that 
changes. 

口 F. We are violating encapsulation of the 
WeatherData class. 
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the observer pattern 


Whafs wrowg with our implemewtatiow? 

Think back to all those Chapter 1 concepts and principles... 


public void measurementsChanged() { 


float temp = getTemperature (); 
float humidity = getHumidity (); 
float pressure = getPressure 。； 


/\vca o( >wc r\ttd 

io chdapsula-tc iKis. 


zlurrentConditionsDisplay.update (temp, humidity, pressure); 
statisticsDisplay.update(temp, humidity, pressure); 
forecastDisplav/update(temp , humidity, pressure); 


By dod'mg to toUrtit 
y/c v^avc no y/ay -to add ov 代 move 
o-t^cv display clcmc^-ts y/i-tV^ou-t 
-to ^vogv-a^. 


A 七 least v/c seem -to be usmg a 
dommorv nvUv*fa6e 七 O talk "to 
display 士 "t^cy all V^avc ar\ 
updatcO takes i\\t 七叶 

^umiai-ty, artd pressure values. 




We’ll take a look at 
Observer, then come 
back and figure out how 
to apply it to the weather 
monitoring app. 
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Meet the Observer Pattern 

You know how newspaper or magazine 
subscriptions work: 

❹ A newspaper publisher goes into business and begins 
publishing newspapers. 

❾ You subscribe to a particular publisher, and every time 
there’s a new edition it gets delivered to you. As long as 
you remain a subscriber, you get new newspapers. 

❾ You unsubscribe when you don’t want papers anymore ， 
and they stop being delivered. 

❹ While the publisher remains in business ， people ， hotels, 
airlines and other businesses constantly subscribe and 
unsubscribe to the newspaper. 



Miss whats going on 
in Objectville? No way, of 
‘ course we subscribe! 
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Publishers + Subscribers s Observer Pattern 


the observer pattern 


If you understand newspaper subscriptions, you pretty much 
understand the Observer Pattern, only we call the publisher 
the SUBJECT and the subscribers the OBSERVERS. 


Let’s take a closer look: 


TKc obsevvevs Kavc substvibed 七。 
(vc^is-bcvcd Y/i*bV>) Subject 
-to vcdcWc updates Y/V>cy> xKc 
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A day iw the life of the Observer Pattern 


A Duck object comes along 
and tells the Subject that 
it wants to become an 
observer. 

Duck really wants in on the 
action; those ints Subject is 
sending out whenever its state 
changes look pretty interesting... 




The Duck object is now an 
official observer. 

Duck is psyched... he’s on the 
list and is waiting with great 
anticipation for the next 
notification so he can get an int. 



The Subject gets a new 
data value! 

Now Duck and all the rest of the 
observers get a notification that 
the Subject has changed. 
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the observer pattern 


The Mouse object asks to be 
removed as an observer. 

The Mouse object has been 
getting ints for ages and is tired 
of it, so it decides it’s time to 
stop being an observer. 



Mouse is outta here! 

The Subject acknowledges the 
Mouses request and removes it 
from the set of observers. 




The Subject has another 
new int. 

All the observers get another 
notification, except for the 
Mouse who is no longer included. 
Don’t tell anyone, but the Mouse 
secretly misses those ints... 
maybe it’ll ask to be an observer 
again some day. 



you are here ► 
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Five minute drama: a subject for observation 

In today’s skit, two post-bubble software developers 
encounter a real live head hunter... 



Software 
Developer #2 
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the observer pattern 


O 


Meanwhile for Ron and Jill life goes 
on; if a Java job comes along, they'll 
get notified, after all, they are ob¬ 
servers. 



o V 

Subject 



Observer 



Observer 
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the observer pattern defined 


Two weeks later:.. 



Jill’s loving life, and no longer an observer. 
She's also enjoying the nice fat signing 
bonus that she got because the company 
didn’t have to pay a headhunter. 


But what has become of our dear Ron? We hear 
hes beating the headhunter at his own game. 

He’s not only still an observer, he’s got his own 
call list now, and he is notifying his own observers. 
Ron’s a subject and an observer all in one. 
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The Observer Pattern defined 


When you're trying to picture the Observer Pattern, a newspaper 
subscription service with its publisher and subscribers is a good 
way to visualize the pattern. 

In the real world however, you’ll typically see the Observer Pattern 
defined like this: 


The Observer Pattern defines a one-to-many 
dependency between objects so that when one 
object changes state, all of its dependents are 
notified and updated automatically. 


Let’s relate this definition to how we've been talking about the 
pattern: 


om TO mMW relationship 



Tke Observer Pattern 
cte^ines a one-to-many 
relationsliip between a set 
oi objects. 


Wken tke state oi one 
otject ckangfes, alt oi its 
ctepenctents are notiiiect. 


The subject and observers define the one-to-many relationship. 
The observers are dependent on the subject such that when the 
subject’s state changes, the observers get notified. Depending on 
the style of notification, the observer may also be updated with 
new values. 

As you’ll discover, there are a few different ways to implement 
the Observer Pattern but most revolve around a class design that 
includes Subject and Observer interfaces. 


Let’s take a look... 
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loose coupling 


The Observer Pattern defined: 
the class diagram 


v\ttA 


tr 






O 




a ;>々 




Mt^ 


i-acM subject 

匕如 \i3VC 

obscwcv-s. 


tailed Y/^cn tnc 
s-tatc tV^awys. 


wst V>as or 

Sub〆 、 


M STf ^ 


«interface» 

observers 

<<interfac6>> 

Subject 

- ► 

Observer 

registerObserver() 

removeObserver() 

notifyObservers() 

updatef) 



卜 adda»o^ to 


广 

c*bc subject 

iw'pUw'C 

isis 

J^od^'-s^d locate 

all -t^e twvvev'-t obewevs 
加 evw state 似呼 s. 


ConcreteSubject 

registerObserver() {...} 
removeObserver() {...} 
notifyObservers() {•••} 

getState() 

setState() 


_ subject 


㈣ 聲二 


ConcreteObserver 

update() 

II other Observer specific 
methods 




Cor\tvc-tc observevs C^y\ be 
ar\y dass -tha-t irwplcrwc^-b -tlic 
Obscwcv m-tev-fatc. Bsdh 
obsewev- vegis-tevs v/i-tli a 6or\6vcic 
subject "to vctcivc updates. 


Duni^C^uestions 

What does this have to do 
with one-to-many relationships? 


How does dependence come 
into this? 


A- 

Jr \* With the Observer pattern, the 
Subject is the object that contains the 
state and controls it. So, there is ONE 
subject with state. The observers, on 
the other hand, use the state, even 
if they don’t own it. There are many 
observers and they rely on the Subject 
to tell them when its state changes. 

So there is a relationship between the 
ONE Subject to the MANY Observers. 


A- 

Jr \* Because the subject is the sole 
owner of that data, the observers are 
dependent on the subject to update 
them when the data changes. This 
leads to a cleaner 00 design than 
allowing many objects to control the 
same data. 
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The power of Loose Coupling 


the observer pattern 


When two objects are loosely coupled, they can interact ， 
but have very little knowledge of each other. 

The Observer Pattern provides an object design where 
subjects and observers are loosely coupled. 


Why? 


The only thing the subject knows about an observer is that it 
implements a certain interface (the Observer interface). It doesn’t need to 
know the concrete class of the observer, what it does, or anything else about it. 

We can add new observers at any time. Because the only thing the subject 
depends on is a list of objects that implement the Observer interface, we can add new 
observers whenever we want. In fact, we can replace any observer at runtime with 
another observer and the subject will keep purring along. Likewise, we can remove 
observers at any time. 

We never need to modify the subject to add new types of observers. Let’s 
say we have a new concrete class come along that needs to be an observer. We don’t 
need to make any changes to the subject to accommodate the new class type, all 
we have to do is implement the Observer interface in the new class and register as 
an observer. The subject doesn’t care; it will deliver notifications to any object that 
implements the Observer interface. 

We can reuse subjects or observers independently of each other. If we 

have another use for a subject or an observer, we can easily reuse them because the 
two aren’t tightly coupled. 


\ Hoy/ >^3^ 


of ^ 


Changes to either the subject or an observer will not affect the other. 

Because the two are loosely coupled, we are free to make changes to either, as long as 
the objects still meet their obligations to implement the subject or observer interfaces. 



Loosely coupled designs allow us to build flexible OO 
systems that can handle change because they minimize 
the interdependency between objects. 
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planning the weather station 


-terpen your pencil 


Before moving on, try sketching out the classes you’ll need to implement the 
Weather Station, including the WeatherData class and its display elements. 
Make sure your diagram shows how all the pieces fit together and also how 
another developer might implement her own display element. 


If you need a little help, read the next page; your teammates are already 
talking about how to design the Weather Station. 
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Cubicle conversation 


Back to the Weather Station project，your teammates have 
already started thinking through the problem... 


广 - - — 

So, how are we 

going to build this thing? 


急 



Mary ： Well, it helps to know we’re using the Observer Pattern. 
Sue ： Right... but how do we apply it? 

Mary ： Hmm. Let’s look at the definition again: 


The Observer Pattern defines a one-to-many dependency between objects so that when one 
object changes state, all its dependents are notified and updated automatically. 

Mary ： That actually makes some sense when you think about it. Our WeatherData 
class is the “one” and our “many” is the various display elements that use the weather 
measurements. 

Sue ： That’s right. The WeatherData class certainly has state... that’s the temperature, 
humidity and barometric pressure, and those definitely change. 

Mary ： Yup, and when those measurements change, we have to notify all the display 
elements so they can do whatever it is they are going to do with the measurements. 


Sue ： Cool, I now think I see how the Observer Pattern can be applied to our Weather 
Station problem. 


Mary ： There are still a few things to consider that I’m not sure I understand yet. 


SU6: Like what? 


Mary ： For one thing, how do we get the weather measurements to the display elements? 

Sue ： Well, looking back at the picture of the Observer Pattern, if we make the 
WeatherData object the subject, and the display elements the observers, then the 
displays will register themselves with the WeatherData object in order to get the 
information they want, right? 

Mary ： Yes... and once the Weather Station knows about a display element, then it can 
just call a method to tell it about the measurements. 

Sue ： We gotta remember that every display element can be different... so I think that’s 
where having a common interface comes in. Even though every component has a 
different type, they should all implement the same interface so that the WeatherData 
object will know how to send them the measurements. 

Mary ： I see what you mean. So every display will have, say，an update0 method that 
WeatherData will call. 

Sue ： And update0 is defined in a common interface that all the elements implement... 
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designing the Weather Station 

How does this diagram compare with yours? 








Mo,v 一如 必 
TW-s r^ at£ 

娜二二 W 

七 0 _ 办如如州的 . 


Lets also dvca*tc a 的 

m-tcv-fa^c *fov all display 
elerwwts 七。 implemetvt. TKc 
display clemetvis jus 七 Y\ttd io 
implcmc^"t 3 displayO me 七 V>od. 


«interface» 

observers 

«interface» 


«interface» 

Subject 


Obse/ver 


DisplayElement 

registerObserver() 

removeObserver() 

notifyObservers() 


update() 


display() 


△ [>v „ . .. 



1 CurrentConditionsDisplay 




WeatherData 


registerObserver() 

removeObserver() 

notifyObservers() 

getTemperature() 

getHumidity() 

getPressure() 

measurementsChanged() 


Wca 七 ⑽ … 
Subject 山 “. 


update() 

display() {II display current 
measurements} 


TW,i display e i erney)i 
snows ihc ^u\r\rcr>i 

柊 。… ihe 

Weaihe^rDah, object 


ThirdPartyDisplay 


StatjstjcsDjspjay 


update() 

display() {II display 
something else based on 
measurements} 


update() 

display() {II display the aver¬ 
age, min and max measure¬ 
ments } 




This or\t keeps -tv-a^k 
o( "the rw'm/avg/ 
mcasuv-cmcr\-b a^d 
displays -therw. 



N 

Pcvclo\>cvs 

£.dr> 

i\\t Obscrvcv- 

d^d P—ay 

|mtcr^atcs to 

Lrcatc 。鄉 

d'»s\>Ia7 clc^cr>t 


TWis d»s\>la 7 s^oYis i\\t >wca-tV>cr 
Uaast based ow tKc barometer. 


These tliv-cc display clcrwc^ts should have a po'm-tev -to 
iVcailicvData labeled w subjct-t w ioo, bu-t boy v/ould 
-this dia^vam start io look like spaghetti i-f -they did- 
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the observer pattern 


Implementing the Weather Station 

We’re going to start our implementation using the class diagram and following Mary 
and Sue’s lead (from a few pages back). You’ll see later in this chapter that Java 
provides some built-in support for the Observer pattern, however, we’re going to get 
our hands dirty and roll our own for now. While in some cases you can make use of 
Java’s built-in support, in a lot of cases it’s more flexible to build your own (and it’s 
not all that hard). So, let’s get started with the interfaces: 


Bo-tK o( these methods -take an 

public interface Subject { / 一 " Obscwcv as an ihai is, 

public void registerObserver (Observer o) \^1 Obscwcv to be or v-emoved- 

public void removeObserver(Observer o); 3 

public void notifyObservers(); 

} This method is dolled "to all obsewevs 

whch 七 he Subject’s s-bic Kas dKahjed. 


public interface Observer { 

public void update (float temp, float humidity, float pressure); 

} ^ T f 

TKcsc avc iKc s-taic values -tKc Obscwcvs yt -fv-om 
iKc Subjcdi >wKch a y/caiKcv* mcasuv-cmcn-t dKa^gcs 


public interface DisplayElement 
public void display(); 



TKc Obscvvcv- is 

by all obscwc\rs, 
so -tKcy all have 七。 

七 he u\>da-tcO mc-tKod- Hcv-c 
y/cVc -follov/mj /V|av*y 
Sues lead and ^ass'mj 
mcasuvcw'Ctvts "to "the obscv'vc'rs. 


TKe PisplayElcmc^i m-tev-fa^c jusi mdludcs 
ot\t mctKod, dis^>layO, -tKa-t v/c will dall wKcr> 
•tKc display needs -to be displayed. 





Mary and Sue thought that passing the measurements directly to the 
observers was the most straightforward method of updating state. Do 
you think this is wise? Hint: is this an area of the application that 
might change in the future? If it did change, would the change be well 
encapsulated, or would it require changes in many parts of the code? 

Can you think of other ways to approach the problem of passing the 
updated state to the observers? 

Don’t worry, we’ll come back to this design decision after we finish the 
initial implementation. 
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ImplementiHg the Subject interface iw 
WeatherPata 

Remember our first attempt at implementing the WeatherData class at the 
beginning of the chapter? You might want to refresh your memory. Now 
it’s time to go back and do things with the Observer Pattern in mind... 


REA^lEA^lBER ： >wc provide 
impovt dhd package s-tatcmc^-ts 

•m -tKc 匕 ode lis-t'mjs. 6 \t{, tKc 
dom^lctc souvdc todt -fvom "tKc 
Kcad-fiv-s-tlabs y/cb si-tc. yWlI 
-r'md -tKc URL on >c>c^iii \v\ 
■tKc livbra 


public class WeatherData implements Subject { ^ ^ ^VcaiKcvPa-ta nov/ 

private ArrayList observers; ^ tKc Subjcdt 


d) 

-p 




private float temperature; 
private float humidity; 
private float pressure; 

public WeatherData() { 

observers = new ArrayList(); 


VVeve added a« AvvayUst io 

hold -tVie Obsevvevs, a«d >we 


l/VKcn an obscv-vcv v-c^istcv-s, y/c jus 七 

public void registerObserver(Observer o) { ^ add it "to end list- 

observers . add (o) ; 


public void removeObserver(Observer o) 
int i = observers.indexOf(o); 
if (i >= 0) { 

observers.remove(i); 

} 


public void notifyObservers() { 

for (int i = 0; i < observers.size(); i++) { 

Observer observer = (Observer)observers.get(i); 
observer.update(temperature, humidity, pressure); 


Likewise, v/Kch art observer wan-b io un-v-caisiev, 
切 c just -take i-t o(( -tKc list 

Hcvc's i\\t -fur\ ^av-t ； tWis is v/c 

tell all obsev-vevs about tKc state- 

Because art all Obscv-vcv-s, y/c 
know -tKcy all implcmcn*t so 

v/C knov/ V>o>w to noti-fy 


} 


public void measurementsChanged() 
notifyObservers(); 

} 




public void setMeasurements (float temperature, 
this.temperature = temperature; 
this.humidity = humidity; 
this.pressure = pressure; 
measurementsChanged(); 


float humidity, float pressure) { 


// other WeatherData methods here 


Okay, while wc v/anted to ship a hide little 
wea-thev- s-tatioh with ea 匕 h book, -the publisKev* 
wouldn't go (or ii So, ra-thev ihdh «-eadih3 
actual weathev data o(( a device, wcVc 
going -to use this method to test ouv display 
dcmchts. O^r, -fov -fuh, you Could y/\r'rtc toAt 
"to gvab mcasuvcmch-ts -the v/eb- 
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Now, let§ build those display elements 


Now that we’ve got our WeatherData class straightened out, it’s time to build the 
Display Elements. Weather-O-Rama ordered three: the current conditions display, the 
statistics display and the forecast display. Let’s take a look at the current conditions 
display; once you have a good feel for this display element, check out the statistics and 
forecast displays in the head first code directory. You’ll see they are very similar. 




so '"t 


public class CurrentConditionsDisplay implements Observer, 
private float temperature; 
private float humidity; 
private Subject weatherData; 

public CurrentConditionsDisplay(Subject weatherData) 
this.weatherData = weatherData; 
weatherData.registerObserver(this); 


㉗ 4 

V 

DisplayElement { 


The do^s-tvu^tov- is passed 
wca-bKcvPa-ta objed-b Subject) 
wc use i-b to vejis-bev 七 he 
display as obsewev. 


public void update (float temperature, 
this.temperature = temperature; 
this.humidity = humidity; 
display(); 

} 


float humidity, float pressure) 


Y/C 


u ? dateO is tailed, v 
save the W and ^\d\bf 

and tall dis\>la 70 . 


public void display() { 

System, out .printIn (''Current conditions : '' + temperature 
+、'F degrees and '' + humidity + ''% humidity"); 

} 



TV^c d»s\>la7() 

Wsi 。认七七 ^ 

ar>d 


Duni^t^uestiPns 


Is updateO the best place to 
call display? 

A. 

厂 In this simple example it made 
sense to call displayO when the values 
changed. However, you are right, 
there are much better ways to design 


the way the data gets displayed. We 
are going to see this when we get to 
the model-view-controller pattern. 

Why did you store a reference 
to the Subject? It doesn’t look 
like you use it again after the 
constructor? 


A. 

-Ml- True, but in the future we 
may want to un-register ourselves as 
an observer and it would be handy 
to already have a reference to the 
subject. 
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testing the weather station 


Power op the Weather Station 

Q First, let’s create a test harness 



The Weather Station is ready to go, all we need is some code to glue 
everything together. Here’s our first attempt. We’ll come back later in 
the book and make sure all the components are easily pluggable via a 
configuration file. For now here’s how it all works: 

public class Weatherstation { 

public static void main(String[] args) { 

WeatherData weatherData = new WeatherData(); 




、，七 


|-f you doi 
wa 灼七 七 0 
dovmlodd "tV'C 
toAt, you 

*tV\CSC 心 

ar\d v*un it 


CurrentConditionsDisplay currentDisplay = 

new CurrentConditionsDisplay(weatherData); 

StatisticsDisplay statisticsDisplay = new StatisticsDisplay(weatherData); 
ForecastDisplay forecastDisplay = new ForecastDisplay(weatherData); 


weatherData.setMeasurements(80, 65, 30.4f); 
weatherData.setMeasurements(82, 70, 29.2f); 
weatherData.setMeasurements(78, 90, 29.2f); 


Simulate ^ 
mcasu\rcwcr\*ts- 


Create -the -three 
displays av\d 
pass 七 he 

object. 


❾ Run the code and let the Observer Pattern do its magic 


I File Edit Window Help StormyWeather | 


% java Weatherstation 

Current conditions : 80.OF degrees and 65.0% humidity 
Avg/Max/Min temperature = 80.0/80.0/80.0 
Forecast: Improving weather on the way! 

Current conditions : 82.OF degrees and 70. 0% humidity 
Avg/Max/Min temperature = 81.0/82.0/80.0 
Forecast: Watch out for cooler, rainy weather 
Current conditions : 78.OF degrees and 90. 0% humidity 
Avg/Max/Min temperature = 80.0/82.0/78.0 
Forecast: More of the same 
% 
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Johnny Hurricane, Weather-O-Rama’s CEO just called, they can’t possibly ship without a Heat Index 
display element. Here are the details: 


The heat index is an index that combines temperature and humidity to determine the apparent 
temperature (how hot it actually feels). To compute the heat index, you take the temperature, T, and the 
relative humidity, RH, and use this formula: 

heatindex = 

16.923 + 1.85212 * 10' 1 * T + 5.37941 ★ RH - 1.00254 * 10 1 * T 

* RH + 9.41695 * 10' 3 * T 2 + 7.28898 * 10_ 3 * RH 2 + 3.45372 * 10 4 

* T 2 ★ RH - 8.14971 * 10 -4 * T * RH 2 + 1.02102 * 1(T 5 ★ T 2 * RH 2 - 
3.8646 * 10- 5 * T 3 + 2.91583 * 10~ 5 * RH 3 + 1.42721 * 10' 6 * T 3 * RH 
+ 1.97483 * I。- 7 * T * RH 3 - 2.18429 * 1(T 8 * T 3 * RH 2 + 8.43296 * 
lO-io * t 2 * RH 3 - 4.81975 * 10 -11 * T 3 * RH 3 

So get typing! 


Just kidding. Don’t worry, you won’t have to type that formula in; just create your own HeatlndexDisplay. 
java file and copy the formula from heatindex.txt into it. 

_^ 7。“ dan yt hea 七 -fvom hcad-fiv-s-tlabs.^om 

How does it work? You’d have to refer to Head First Meteorology, or try asking someone at the National 
Weather Service (or try a Google search). 


When you finish, your output should look like this: 



% java Weatherstation 

Current conditions : 80.OF degrees and 65. 0% humidity 
Avg/Max/Min temperature = 80.0/80.0/80.0 
Forecast: Improving weather on the way! 

Heat index is 82.95535 

Current conditions : 82.OF degrees and 70. 0% humidity 
Avg/Max/Min temperature = 81.0/82.0/80.0 
Forecast: Watch out for cooler, rainy weather 
Heat index is 86.90124 

Current conditions : 78.OF degrees and 90. 0% humidity 
Avg/Max/Min temperature = 80.0/82.0/78.0 
Forecast: More of the same 
Heat index is 83.64967 
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fireside chat: subject and observer 


Fireside Ghats 



Tonight’s talk ： A Subject and Observer spar over the right 
way to get state information to the Observer. 


Subject Observer 

I’m glad we’re finally getting a chance to chat in 

person. Really? I thought you didn’t care much about 

us Observers. 

Well, I do my job, don’t I? I always tell you what’s 
going on... Just because I don’t really know who 
you are doesn’t mean I don’t care. And besides，I 
do know the most important thing about you — 
you implement the Observer interface. 

Well yeah, but that’s just a small part of who I 
am. Anyway, I know a lot more about you... 

Oh yeah, like what? 

Well ， you’re always passing your state around 
to us Observers so we can see what’s going 
on inside you. Which gets a little annoying at 
times... 

Well excuuuse me. I have to send my state with my 
notifications so all you lazy Observers will know 
what happened! 

Ok, wait just a minute here; first, we’re not lazy, 
we just have other stuff to do in between your 
oh-so-important notifications, Mr. Subject, and 
second，why don’t you let us come to you for 
the state we want rather than pushing it out to 
just everyone? 


Well... I guess that might work. I’d have to open 
myself up even more though to let all you Observers 
come in and get the state that you need. That might 
be kind of dangerous. I can’t let you come in and 
just snoop around looking at everything I’ve got. 
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Subject 


Yes，I could let you pull my state. But won’t that be 
less convenient for you? If you have to come to me 
every time you want something, you might have to 
make multiple method calls to get all the state you 
want. That’s why I like push better... then you have 
everything you need in one notification. 


Well, I can see the advantages to doing it both ways. 
I have noticed that there is a built-in Java Observer 
Pattern that allows you to use either push or pull. 


Great... maybe I’ll get to see a good example of 
pull and change my mind. 


Observer 

Why don’t you just write some public getter 
methods that will let us pull out the state we 
need? 


Don’t be so pushy! There’s so many different 
kinds of us Observers, there’s no way you can 
anticipate everything we need. Just let us come 
to you to get the state we need. That way，if 
some of us only need a little bit of state, we 
aren’t forced to get it all. It also makes things 
easier to modify later. Say, for example, you 
expand yourself and add some more state, well 
if you use pull, you don’t have to go around 
and change the update calls on every observer, 
you just need to change yourself to allow more 
getter methods to access our additional state. 


Oh really? I think we’re going to look at that 
next.... 


What, us agree on something? I guess there’s 
always hope. 
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Using Java's built - iw 
Observer Pattern 

So far we’ve rolled our own code for the 
Observer Pattern, but Java has built-in support 
in several of its APIs. The most general is the 
Observer interface and the Observable class in 
the java.util package. These are quite similar 
to our Subject and Observer interface, but give 
you a lot of functionality out of the box. You 
can also implement either a push or pull style of 
update to your observers, as you will see. 

To get a high level feel for java.util. Observer and 
java.util.Observable, check out this reworked 
OO design for the WeatherStation: 




observers 




Observable is a 
CLASS hO"t By\ 
m-tcir-Patc, so 

l^cathcvPata 

c^*tcr>ds Observable 


Observable 

addObserver() 

deleteObserver() 

notifyObservers() 

setChanged() 


喊七 ） a set- 


WeatherData 

getTemperature() 

getHumidity() 

getPressure() 


J o ^«j0bsev' ( «' rs0 七以 

: t : 二一七祕一 
W 如 s^evtlass. 
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How Java's built-iw Observer Pattern works 

The built in Observer Pattern works a bit differently than the implementation that we used 
on the Weather Station. The most obvious difference is that WeatherData (our subject) 
now extends the Observable class and inherits the add, delete and notify Observer methods 
(among a few others). Here’s how we use Java’s version: 

For an Object to become an observer... 

As usual, implement the Observer interface (this time the java.util.Observer 
interface) and call addObserverQ on any Observable object. Likewise, to remove 
yourself as an observer just call deleteObserverQ. 


For the Observable to send notifications... 


First of all you need to be Observable by extending the java.util.Observable 
superclass. From there it is a two step process: 


❶ 

O 


You first must call the setChanged() method to signify 
that the state has changed in your object 

Then, call one of two notifyObservers() methods: 

either notifyObservers () or notifyObservers(Object arg) 



“ A ^4-a ov\^^ 


For an Observer to receive notifications... 



It implements the update method, as before, but the signature of the 
method is a bit different: 


update(Observable o, Object arg) 


e oi tne yr 


The Subject -tliat sort 

"the r\o-ti-ri^a*tioh is passed 
•m as "this avgurwCht 


This v/ill be -the daia object -that v/as 
passed -to r\o-ti-fyObscvvcvsO ; ov hull i-f 
a daia obje 乙七 speti-f ied. 


If you want to “push” data to the observers you can pass the data as a data object 
to the notifyObserver(arg) method. If not, then the Observer has to “pull” the data 
it wants from the Observable object passed to it. How? Let’s rework the Weather 
Station and you’ll see. 
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behind the scenes 


Wait, before we get 
to that, why do we need this 
setChanged() method? We didn’t 
need that before. 



The setChangedO method is used to signify that the state has changed and that notifyObserversQ 
when it is called, should update its observers. If notifyObserversO is called without first calling 
setChangedO, the observers will NOT be notified. Let’s take a look behind the scenes of 
Observable to see how this works: 


Beldnd 

tire Scenes'* 




办 t 


setChangedO { 
changed =true 


notifyObservers(Object arg) { 
if (changed) { 

for every observer on the list { 
call update (this, arg) 

} 

changed = false 


notifyObserversO { 
notifyObservers(null) 


The se-tC^a^edO me&d 

se-b a Aa— ^ 七 0 卜此 . 

a-ftcv it r\o-bi-f ics 
obscwcvs, i-t sets 七 he 
-fla^ batk -bo -false- 


Why is this necessary? The setChangedO method is meant to give you more flexibility in how 
you update observers by allowing you to optimize the notifications. For example, in our weather 
station, imagine if our measurements were so sensitive that the temperature readings were 
constantly fluctuating by a few tenths of a degree. That might cause the WeatherData object 
to send out notifications constantly. Instead, we might want to send out notifications only if the 
temperature changes more than half a degree and we could call setChangedO only after that 
happened. 

You might not use this functionality very often, but it’s there if you need it. In either case, you 
need to call setChangedO for notifications to work. If this functionality is something that is useful 
to you, you may also want to use the clearChangedO method, which sets the changed state back to 
false, and the hasChangedQ method, which tells you the current state of the changed flag. 
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the observer pattern 


Reworking the Weather Station with the built - iw support 

First, let’s rework WeatherData to use 
java.util.Observable 


❹ yVlakc suvc wc av-c impovtrnj "tKc 
vi^-t Obscwcv/Obscwablc- 


import java.util.Observable; 
import j ava.util.Observer; 


❾ ❺ iVe do^-t Y\ctd "to keep -tva^k o( 

iVc are y\o^i ouv observers ar>yrwovc, ov manage 

subdldss'm^ Obscwablc- theiv vc^is-tvatioh a^d vc^oval, 

(-the supcv^lass v/ill handle 
so y/c^vc verwoved "the Code (or 
vc^is-tcv, add ay\d r>o-ti-fy. 



public class WeatherData extends Observable 
private float temperature; 
private float humidity; 
private float pressure; 

public WeatherData() { } 


public void measurementsChanged() { 
setChanged(); e 

notifyObservers (); 來 


public void setMeasurements (float temperature, 
this.temperature = temperature; 
this.humidity = humidity; 
this.pressure = pressure; 
measurementsChanged(); 


public float getTemperature () 
return temperature; 

} 



Ovr £.oy\s-tvud-tov- y\o lo^jcv 
^ceds *to dvc 3 *tc a dats 
s-bvud-buvc -to \\o\d Obscvvcv-s. 

來 Notice wc av-c^-t ser>dm^ a data objed-t v/i*th 

-the hoti-PyObscrvcvsf) 乙 all. Thai medr\s 

wcVc us'mj "the PULL model. 


humidity, float pressure) 


Wc r\ov/ -f i\rs*t 11 "to 

mdi^a-tc -the state has 

bc-povc 乙 a 11 mg ho-ti-py Obsc\r vc\rs(). 


public float getHumidity () 
return humidity; 


public float getPressure () 
return pressure; 



TKcsc methods aver / 七 but 

because we av-c *to use w pul 「 
we we’d vcmmd you 

-bKcy avc hevc. T^c Obscwcvs 
will use "to yt a 七 *bhc 
1/Vca-t^cvPata object's state. 
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current conditions rework 


Now ， let’s rework the CurrentConditionsDisplay 


A make suvc v/c avc impovtmj 

-the vijht Obscwcv/Obscvvablc. 


❾ 1/Vc nov/ avc implcmc^trnj t^c Obscwcv mtev-fate *(Vom java.util. 


import java.util.Observable; 
import j ava.util.Observer; 

public class CurrentConditionsDisplay implements Observer, DisplayElement { 
Observable observable; 
private float temperature; 
private float humidity; 


public CurrentConditionsDisplay(Observable observable) 
this.observable = observable; 
observable.addObserver(this); 

} 




public void update(Observable obs. Object arg) { 
if (obs instanceof WeatherData) { 

WeatherData weatherData = (WeatherData)obs; 
this.temperature = weatherData.getTemperature(), 
this.humidity = weatherData.getHumidity(); 
display(); 


❾ Ouv £.oy\s-tvud.-tov y\o^i "takes Br\ 
Observable a^d wc use this -to 
add tKc duvve^-b do^ditioy\s 
objedt as Obscwcv. 


O dhahged -the 
updatcO meihod 

io iakc both ah 

Observable ar>d -the 
optional da-ta avgumcht 


public void display() { 

System, out .printIn (''Current conditions : '' + temperature 
+、'F degrees and '' + humidity + ''% humidity"); 

} 


❺ 


|h updatcO, y/C -fivst 
suve the observable 
is o( type iVcathcv-Pata 
thch y/c use i*ts 
gettev* rwethods to 
obtain 七 he terwpevatuve 
and hui^icli-ty 
mcasuvcrwChis- /Vftcv* 
tha-t wc ^all displayO. 
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Code Magnets 


the observer pattern 


The ForecastDisplay class is all scrambled up on the fridge. Can you 
reconstruct the code snippets to make it work? Some of the curly 
braces fell on the floor and they were too small to pick up, so feel 
free to add as many of those as you need! 


display ()； 


observable.addObserver(this )； 


if (observable instanceof WeatherData) { 


public class ForecastDisplay implements 
Observer, DisplayElement { 

?ub i/ 


、 O sS . 


o’ 


o’ 






public void update ^uose. 

Object arg) I 


able observable, 


"import java.util. Observable; 
import java. util.Observer, 
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test drive 


Running the new code 

Just to be sure, let’s run the new code... 


I File Edit Window Help TryTihisAtHome | 


% java Weatherstation 

Forecast: Improving weather on the way! 

Avg/Max/Min teirperature = 80.0/80.0/80.0 
Current conditions : 80.OF degrees and 65. 0% humidity 
Forecast: Watch out for cooler, rainy weather 
Avg/Max/Min teirperature = 81.0/82.0/80.0 
Current conditions : 82.OF degrees and 70. 0% humidity 
Forecast: More of the same 
Avg/Max/Min temperature = 80.0/82.0/78.0 
Current conditions : 78.OF degrees and 90.0% humidity 
% 


Hmm, do you notice anything different? Look again... 

You’ll see all the same calculations, but mysteriously, the order of the text output is 
different. Why might this happen? Think for a minute before reading on... 


Never depend on order of evaluation of the 
Observer notifications 

The java.util.Observable has implemented its notifyObservers。method such that the 
Observers are notified in a different order than our own implementation. Who’s right? 
Neither; we just chose to implement things in different ways. 

What would be incorrect, however, is if we wrote our code to depend on a specific 
notification order. Why? Because if you need to change Observable/Observer 
implementations, the order of notification could change and your application would 
produce incorrect results. Now that’s definitely not what we’d consider loosely coupled. 
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the observer pattern 


Doesn't 

java. util. Observable 
violate our 00 design principle 
of programming to interfaces 
not implementations? 


The dark side of java.otil.Observable 

Yes, good catch. As you’ve noticed, Observable is a class, not an interface, and worse, 
it doesn’t even implement an interface. Unfortunately, the java.util.Observable 
implementation has a number of problems that limit its usefulness and reuse. That’s not 
to say it doesn’t provide some utility, but there are some large potholes to watch out for. 


Observable is a class 

You already know from our principles this is a bad idea, but what harm does it really 
cause? 

First, because Observable is a class, you have to subclass it. That means you can’t add 
on the Observable behavior to an existing class that already extends another superclass. 
This limits its reuse potential (and isn’t that why we are using patterns in the first place?). 

Second, because there isn’t an Observable interface, you can’t even create your own 
implementation that plays well with Java’s built-in Observer API. Nor do you have 
the option of swapping out the java.util implementation for another (say, a new, multi¬ 
threaded implementation). 

Observable protects crucial methods 

If you look at the Observable API, the setChangedO method is protected. So what? Well, 
this means you can’t call setChangedO unless you’ve subclassed Observable. This means 
you can’t even create an instance of the Observable class and compose it with your own 
objects, you have to subclass. The design violates a second design principle here.. Savor 
composition over inheritance. 



What to do? 


Observable may serve your needs if you can extend java.util. Observable. On the other 
hand, you may need to roll your own implementation as we did at the beginning of the 
chapter. In either case, you know the Observer Pattern well and you’re in a good position 
to work with any API that makes use of the pattern. 
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observer and swing 


Other places yooll find the Observer Pattern 
iwthe JPK 


The java.util implementation of Observer/Observable is not the only place you’ll 
find the Observer Pattern in the JDK; both JavaBeans and Swing also provide their 
own implementations of the pattern. At this point you understand enough about 
observer to explore these APIs on your own; however, let’s do a quick, simple Swing 
example just for the fun of it. 

A little background... 


$ «j 0 «*Ve tw.iow abow-t 
iJoWverPatW 


Let’s take a look at a simple part of the Swing API, theJButton. If you look under 
the hood atJButton 5 s superclass, AbstractButton, you’ll see that it has a lot of add/ 
remove listener methods. These methods allow you to add and remove observers, 
or as they are called in Swing, listeners, to listen for various types of events that 
occur on the Swing component. For instance, an ActionListener lets you “listen in” 
on any types of actions that might occur on a button, like a button press. You’ll find 
various types of listeners all over the Swing API. 

A little life-changing application 

Okay, our application is pretty simple. You’ve got a button that says “Should I do 
it?” and when you click on that button the listeners (observers) get to answer the 
question in any way they want. We’re implementing two such listeners, called the 
AngelListener and the DevilListener. Here’s how the application behaves: 







U*t 於 


File Edit Window—*Help I 


Pevil answev — 
l\^\ answev 




% java SwingObserverExample 
Come on, do it! 

Don't do it, you might regret it! 
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the observer pattern 


And the code 


This life-changing application requires very little code. All we need to do is 
create aJButton object, add it to aJFrame and set up our listeners. We’re going 
to use inner classes for the listeners, which is a common technique in Swing 
programming. If you aren’t up on inner classes or Swing you might want to 
review the “Getting GUI” chapter of Head First Java. 


public class SwingObserverExample { 
JFrame frame; 


that 






public static void main(String[] args) { 

SwingObserverExample example = new SwingObserverExample(); 
example.go(); 

} 


public void go() { 

frame = new JFrame(); 

JButton button = new JButton (''Should 工 do it ?”） 
button.addActionListener(new AngelListener()); 


Makes devil 

扣 yl obje^-b lisicy\cv-s 
(obsewev-s) of buttem 


button.addActionListener(new DevilListener()); 

frame.getContentPane().add(BorderLayout.CENTER, button); 


// Set frame properties here 


} 


class AngelListener implements ActionListener { 

public void actionPerformed(ActionEvent event) { 

System, out .print In (''Don f t do it, you might regret it !〃）； 


} 


class DevilListener implements ActionListener { 

public void actionPerformed(ActionEvent event) 
System, out .println (''Come on, do it!"); 


i Q kc) 


} 



Ra*tV>cv upda-tcO, -the 
attio^Pcv-fovmcdO method 
yb called {ht s-ta-tc 
•m subje 乙七 （m tasc 

■the butt 。”） 
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Tools for your design Toolbox 

Welcome to the end of Chapter 2. 
You’ve added a few new things to your 
OO toolbox... 



OC 

m 七 
>/d 


ok 一 cWs tT 二 - 一 

aVA W 办询 


pa*t*tc\rr\ -fov- torwmuhitatrnj S"ta*tc "to d 
sc*t o( objects m a loosely Coupled marmev. lA^c 
havc^i seen las-t o( ihc Obscwcv- Paiicv^ 
- jus 七 Wrt until v/C talk abou-t M\/C! 


^ BULLET POINTS — 

■ The Observer Pattern defines 
a one-to-many relationship 
between objects. 

■ Subjects, or as we also know 
them, Observables, update 
Observers using a common 
interface. 

■ Observers are loosely coupled 
in that the Observable knows 
nothing about them, other 
than that they implement the 
Observer Interface. 

■ You can push or pull data from 
the Observable when using 
the pattern (pull is considered 
more “correct”). 

■ Don’t depend on a specific 
order of notification for your 
Observers. 

■ Java has several 
implementations of the 
Observer Pattern, including 
the general purpose java.util. 
Observable. 

■ Watch out for issues with 
the java.util.Observable 
implementation. 

■ Don’t be afraid to create 
your own Observable 
implementation if needed. 

■ Swing makes heavy use of the 
Observer Pattern, as do many 
GUI frameworks. 

■ You’ll also find the pattern in 
many other places, including 
JavaBeans and RMI. 
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Design Principle Ckaltenge 

For each design principle, describe how the Observer Pattern 
makes use of the principle. 
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crossword puzzle 



Time to give your right brain something to do again! 
This time all of the solution words are from chapter 2. 



Across 

1. Observable is a_not an interface 

3. Devil and Angel are_to the button 

4. Implement this method to get notified 

5. Jill got one of her own 

6. CurrentConditionsDisplay implements this 
interface 

8. How to get yourself off the Observer list 

12. You forgot this if you're not getting notified 
when you think you should be 

15. One Subject likes to talk to_observers 

18. Don't count on this for notification 

19. Temperature, humidity and_ 

20. Observers are_on the Subject 

21. Program to an_not an 

implementation 

22. A Subject is similar to a_ 


Down 

2. Ron was both an Observer and a_ 

3. You want to keep your coupling_ 

7. He says you should go for it 

9. _can manage your observers for you 

10. Java framework with lots of Observers 

11. Weather-O-Rama's CEO named after this 
kind of storm 

13. Observers like to be_when 

something new happens 

14. The WeatherData class_the 

Subject interface 

16. He didn't want any more ints, so he removed 
himself 

17. CEO almost forgot the_index display 

19. Subject initially wanted to_all the data 

to Observer 
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Exercise 

solutions 



Design Principle 

Identify the aspects of your application that 
vary and separate them from what stays the 
same. 



Design Principle 

Program to an interface, not an implementation. 


Design Principle 

Favor composition over inheritance. 


the observer pattern 


i^^rpen your pencil 



Based on our first implementation, which of the following apply? 

(Choose all that apply.) 

QT A. We are coding to concrete 

implementations, not interfaces. 

□ 

D. The display elements don’t implement a 
common interface. 

0 B. For every new display element we need 
to alter code. 

oT 

E. We haven’t encapsulated what changes. 

^ C. We have no way to add display 
elements at run time. 

□ 

F. We are violating encapsulation of the 
WeatherData class. 


The 七 Wm 巧七 ha 七 vavies m 七 he Obsewev Pa 七七 evn 
is -tKe s-ta-te -tKe Subjed-t -the «u»\bev and 

•by^es Obsevvevs. W\{h -tKis you dan 

vavy -the objed-b iha 七 ave depewdoi-t ov\ -tKe s-ta-te 
<^c -the Subjcd*t, v/i-tKou-t *to "tha 七 
Subjcd-t- Tha^ts called ahead! 


Bo~bh 七 he Sub\ed 七 a^d Obsewev use m-bev-l-ades. 
TKc Subjed-t keeps -tvadk objed-ts iwplemeh-t- 
-the Obsewev m-tev^ade, y/hile -tKe obsewevs 

<re^is-tev y/i-tK, and yt Mo-ti-Pied by, -tKe Subjed-t 

'm-tev-PaCe- As y/e、e seen, -tKis keeps hide 

a^d loosely toupled. 


The Obse<rvev Pa~b~lev>^ uses dor»posi-fcioh -bo dowpose 
3r\y humbev Obsevvers >wi-th -theiv Subjed-ts. 
TKcse velatiohships are〆 七 set by some kind o^ 
mKevi-tande Kieva'rdhy. No, -tKcy are set up a-t 
VUhtime by dorwposi-tioh| 
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exercise solutions 



Code Magnets 


,import java. util. Observable; 

( 1 import java.uti^^e^e^ 

public class ForecastDisplay implements 
Observer, DisplayElement { 



Exercise 

solutions 
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3 the 触 rpattern 


^Decorating Objects + 



Just call this chapter “Design Eye for the Inheritance Guy.” 

Well re-examine the typical overuse of inheritance and you’ll learn how to decorate 
your classes at runtime using a form of object composition. Why? Once you know the 
techniques of decorating, you’ll be able to give your (or someone else’s) objects new 
responsibilities without making any code changes to the underlying classes. 


this is a new chapter 
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the starbuzz story 


Welcome to Starbuzz Coffee 

Starbuzz Coffee has made a name for itself as the 
fastest growing coffee shop around. If you’ve seen 
on your local corner，look across the street; you’ll se< 
another one. 


Because they’ve grown so quickly, they’re scrambling 
to update their ordering systems to match their 
beverage offerings. 

When they first went into business they designed their 
classes like this... 






TKc 60s 七 0 wc*t^od 
abs 七 va^t; subdassscs 
io dc-fmc 七 

ovm 1 叫灼 . 




Beverage 


description 


getDescriptionO 

cost() 

II Other useful methods... 


XV>c vav»ablc 

is sc 七 m tacM subclass a^d holds a 
dcs6vift«o^ Jc -tV>c bevevay Jkc 
w Mos 七 Pav-k Roast • 

TKc ytPcsdriftio^O mrtW 
vcW^s i\\t dcs^viftio^. 



HouseBlend 

DarkRoast 

Decaf 

Espresso 

cost() 

cost() 

cost() 

cost 。 


/ 


subclass dos*t() *to \rc*tuv*h tos*t of 七 he bcvcvajc- 
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the decorator pattern 


In addition to your coffee, you can also ask for several condiments like 
steamed milk, soy, and mocha (otherwise known as chocolate), and have 
it all topped off with whipped milk. Starbuzz charges a bit for each of 
these, so they really need to get them built into their order system. 

Here’s their first attempt... 
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violating design principles 


… - 

It’s pretty obvious that Starbuzz has created a maintenance nightmare for 
themselves. What happens when the price of milk goes up? What do they do 
when they add a new caramel topping? 

Thinking beyond the maintenance problem, which of the design principles that 
we’ve covered so far are they violating? 

jAeM 6!q e u! luolii ;o om; 6i/"e/o//i a/‘Xa ㈧ :; u/h 



Well, let's give it a try. Let's start with the Beverage base 
class and add instance variables to represent whether or 
not each beverage has milk, soy, mocha and whip... 


Now booled^ values -for 


Ko>w we’ll irwplcmchi 乙 os 七 0 m Bcvcvajc (ms-tcad o-f 
keeping i*t so 七 i 七乙扣 

dosts associated wi 七 h -for a pav-ti^ulav- 

beveray Subclasses y/ill still ovcirv-idc 

dosiO, but -t^cy y/ill also invoke 七 he super version so 
-t^ai i^cy takulaic {ht -total tosi o( basit 
bevcv-ay plus 七 lie tosts of -the added 乙 cmdirwe»vb. 

values U co^t^ 
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Now let's add in the subclasses, one 
for each beverage on the menu ： 

TVie — as 此 亡巧 

t 。山 L a “ - 

i^e overvidde*' ^ ^ 

bevevay , l . 

UtM t osK ) 以細七。 to :— 
Hi J 如 beveray ^ 


Severage 


description 
milk 
soy 
mocha 
whip 

getDescriptionf) 

今 cost() 

hasMilkQ 

setMilk() 

hasSoy() 

setSoy() 

hasMocha() 

setMocha() 

hasWhip() 

setWhip() 

II Other useful methods.. 



HouseBlend 

DarkRoast 

Decaf 

Espresso 

cost() 

cost() 

cost() 

cost() 


- Sharpen your pencil 


Write the cost() methods for the following classes (pseudo-Java is okay): 


public class Beverage { 
public double cost() { 


public class DarkRoast extends Beverage { 
public DarkRoast() { 

description = ''Most Excellent Dark Roast”; 

} 

public double cost() { 
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impact of change 



What requirements or other factors might change that will impact this design? 


Pv-i^c -fov tondirwChts v/ill -forte us "to al*tcv- Code 


Mcyj 乙 or>dirwc»vts y/ill -forte us \jo add hew methods al*tc\r -the tos*t me*tliod m "the supcv-tlass. 
We r»ay have r>cw bevevajes. Fov some c^P -these bcvcv-agcs i\ctA -tea?), -the 乙 ohdirweivb 



l/Vhat i-P a ^us-torwcir v/ar\ts a double motlia? 


和 w. 
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fXt'iK . 

1 Master and Student... 

a Master: Grasshopper, it has been some time since our last 

meeting. Have you been deep in meditation on inheritance? 

Student: Yes, Master. While inheritance is powerful, I have 
learned that it doesn’t always lead to the most flexible or 
maintainable designs. 

Master: Ah yes, you have made some progress. So, tell me my student, how 
then will you achieve reuse if not through inheritance? 

Student: Master, I have learned there are ways of “inheriting” behavior at 
runtime through composition and delegation. 

Master: Please, go on... 

Student: When I inherit behavior by subclassing, that behavior is set statically 
at compile time. In addition, all subclasses must inherit the same behavior. If 
however, I can extend an object’s behavior through composition, then I can do 
this dynamically at runtime. 

Master: Very good, Grasshopper, you are beginning to see the power of 
composition. 

Student: Yes, it is possible for me to add multiple new responsibilities to objects 
through this technique, including responsibilities that were not even thought of 
by the designer of the superclass. And, I don’t have to touch their code! 

Master: What have you learned about the effect of composition on maintaining 
your code? 

Student: Well, that is what I was getting at. By dynamically composing objects, 

I can add new functionality by writing new code rather than altering existing 
code. Because l，m not changing existing code, the chances of introducing bugs 
or causing unintended side effects in pre-existing code are much reduced. 

Master: Very good. Enough for today, Grasshopper. I would like for you to 
go and meditate further on this topic... Remember，code should be closed (to 
change) like the lotus flower in the evening, yet open (to extension) like the 
lotus flower in the morning. 
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the open-closed principle 


The Open-Closed Principle 

Grasshopper is on to one of the most important design principles: 




CLOSED 

BUSINESS HOURS ： 



extensions. 



Sorry, we’re closed. 

That’s right, we spent 
a lot of time getting this code correct and 
bug free, so we can’t let you alter the existing code. 
It must remain closed to modification. If you don’t 
like it, you can speak to the manager. 


Our goal is to allow classes to be easily extended to 
incorporate new behavior without modifying existing code. 
What do we get if we accomplish this? Designs that are 
resilient to change and flexible enough to take on new 
functionality to meet changing requirements. 
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DumPc^iiestiPiis 


Open for extension and closed 
for modification? That sounds very 
contradictory. How can a design be 
both? 

That’s a very good question. It 
certainly sounds contradictory at first. 
After all, the less modifiable something 
is, the harder it is to extend, right? 

As it turns out, though, there are some 
clever 00 techniques for allowing 
systems to be extended, even if we can’t 
change the underlying code. Think 
about the Observer Pattern (in Chapter 
2)... by adding new Observers, we can 
extend the Subject at any time, without 
adding code to the Subject. You’ll see 
quite a few more ways of extending 
behavior with other 00 design 
techniques. 

Okay, I understand Observable, 
but how do I generally design 
something to be extensible, yet closed 
for modification? 

Many of the patterns give us 
time tested designs that protect your 
code from being modified by supplying 
a means of extension. In this chapter 
you’ll see a good example of using the 
Decorator pattern to follow the Open- 
Closed principle. 


How can I make every part of 
my design follow the Open-Closed 
Principle? 


Usually,you can’t. Making 00 
design flexible and open to extension 
without the modification of existing 
code takes time and effort. In general, 
we don’t have the luxury of tying down 
every part of our designs (and it would 
probably be wasteful). Following 
the Open-Closed Principle usually 
introduces new levels of abstraction, 
which adds complexity to our code. 

You want to concentrate on those areas 
that are most likely to change in your 
designs and apply the principles there. 

How do I know which areas of 
change are more important? 

That is partly a matter of 
experience in designing 00 systems and 
also a matter of knowing the domain 
you are working in. Looking at other 
examples will help you learn to identify 
areas of change in your own designs. 


Wkile it may seem like a contractiction, 
tkere are teclmifjues for allowing code to te 
extenctect witkout ctirect moctiiication. 


Be careful wken ckoosingf tke areas oi cocte 
tkat neect to te extenctect; applying tke 
Open-Closect Principle EVERYWHERE 
is wasteful, unnecessary, anct can lead to 
complex, karct to uncterstanct cocte. 
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meet the decorator pattern 


Meet the decorator Pattern 


Okay, enough of the ''Object 
Oriented Design Club." We have real 
problems here! Remember us? Starbuzz 
Coffee? Do you think you could use 
some of those design principles to 
actually help us? 


Okay, we’ve seen that representing our beverage plus condiment pricing 
scheme with inheritance has not worked out very well - we get class 
explosions, rigid designs, or we add functionality to the base class that isn’t 
appropriate for some of the subclasses. 

So, here’s what we’ll do instead: we’ll start with a beverage and “decorate” 
it with the condiments at runtime. For example, if the customer wants a 
Dark Roast with Mocha and Whip, then we’ll: 


❹ Take a DarkRoast object 
❺ Decorate it with a Mocha object 



O Decorate it with a Whip object 

O Call the cost() method and rely on 

delegation to add on the condiment costs 


Okay, but how do you ‘‘decorate’’ an object, and how does delegation 
come into this? A hint: think of decorator objects as “wrappers.” Let’s 
see how this works... 
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Constructing a driwk order with decorators 


the decorator pattern 


❹ We start with our DarkRoast object. 





❾ The customer wants Mocha, so we create a Mocha 
object and wrap it around the DarkRoast. 

TV>e MotV>a o\>\^ ' s 

切? 一“心 w ”， 



m tW»s tase, a 




vt \s tv^ 




咖..） 


in *to°) 


❺ The customer also wants Whip, so we create a 
Whip decorator and wrap Mocha with it. 



So, a PavkRoas-t v/rapped *m Motha a^d Whip is s-till 
a Beverage a^d v/e do v/i 七 h i*t v/e tan do 

v/i-tli a PavkRoas-t) mdudm^ ^all 'rts tos*tO method. 
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decorator characteristics 


Q Now it’s time to compute the cost for the customer. We do this 
by calling cost() on the outermost decorator, Whip, and Whip is 
going to delegate computing the cost to the objects it decorates. 
Once it gets a cost, it will add on the cost of the Whip. 

(V^U see 


❾ Whip calls cost() on I 


(Vo^u 

a 


a •Vc'w ? a y ! 


: s) 



A First, we call cost() on the 
outmost decorator, Whip. 


Mocha calls cost() on 
DarkRoast. 


$ 1.29 


❹ DarkRoast 
^ returns its cost, 
99 cents. 


Q Whip adds its total, 10 cents, 
to the result from Mocha, and 
returns the final result—$1.29. 


A Mocha adds its cost, 20 
W cents, to the result from 


DarkRoast, and returns 
the new total, $1.19. 


Okay, here's what we know so far.. 

■ Decorators have the same supertype as the objects they decorate. 

■ You can use one or more decorators to wrap an object. 

■ Given that the decorator has the same supertype as the object it decorates, we can pass 
around a decorated object in place of the original (wrapped) object. 

■ The decorator adds its own behavior either before and/or after delegating to the object it f i 
decorates to do the rest of the job. 

■ Objects can be decorated at any time, so we can decorate objects dynamically at runtime 
with as many decorators as we like. 


Now lefs see how this all really works by looking at the 
Pecorator Pattern definition and writing some code. 
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the decorator pattern 


The decorator Pattern defined 


Let’s first take a look at the Decorator Pattern description: 


The Decorator Pattern attaches additional 
responsibilities to an object dynamically. 
Decorators provide a flexible alternative to 
subclassing for extending functionality. 


While that describes the role of the Decorator Pattern, it doesn’t give us a lot 
of insight into how we’d apply the pattern to our own implementation. Let’s 
take a look at the class diagram, which is a little more revealing (on the next 
page we’ll look at the same structure applied to the beverage problem). 

dompohCht dah be used or\ its 



Pcdovatovs tar\ add nev/ mc-t^ods ； ⑽ w 

behavior is -typidally added by dom^ dompu-ta-bio^ 
bc-fov-c or a-rtev* method 'm dompor\c^*t- 
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decorating beverages 


Pecoratiwg our leverages 

Okay ， let’s work our Starbuzz beverages into this framework... 


亡?一 ^ lass . 




Beverage 


description 


getDescription() 

cosf(} 

II other useful methods 


HouseBlend 

DarkRoast 

cost() 

cost() 


Espresso 


cost() 


Decaf 


:ost() 





爲 V 


Milk 

Mocha 

Soy 

Whip 

Beverage beverage 

Beverage beverage 

everage beverage 

Beverage beverage 

cost() 

getDescription() 

cost() 

getDescription() 

)st() 

BtDescription() 

cost() 

getDescription() 


\ \ T P 

hcvc Brt ouv- dohdir^ivt dc^ovatov-s ； hotidc 
"to implc 你 ovt ho 七 ohly dos*tO bu 七 also 

gctPcsdrip-tiohO. Wc\\ SCC why ih a rwom ⑶七 … 





Before going further, think about how you’d implement the cost() method of 
the coffees and the condiments. Also think about how you’d implement the 
getDescription() method of the condiments. 
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the decorator pattern 


Cubicle Conversation 


Some confusion over Inheritance versus Composition 

.^Okay" rrrTa^ittle 

confused...I thought we weren't 
going to use inheritance in this 
O v pattern, but rather we were going 
" to rely on composition instead. 




\ 

m 


Sue ： What do you mean? 

Mary ： Look at the class diagram. The CondimentDecorator is extending the Beverage class. 
That’s inheritance, right? 

Sue ： True. I think the point is that it’s vital that the decorators have the same type as the 
objects they are going to decorate. So here we’re using inheritance to achieve the type matching, 
but we aren’t using inheritance to get behavior. 

Mary ： Okay, I can see how decorators need the same “interface” as the components they wrap 
because they need to stand in place of the component. But where does the behavior come in? 

Sue ： When we compose a decorator with a component, we are adding new behavior. We 
are acquiring new behavior not by inheriting it from a superclass, but by composing objects 
together. 


Mary ： Okay, so we’re subclassing the abstract class Beverage in order to have the correct type, 
not to inherit its behavior. The behavior comes in through the composition of decorators with 
the base components as well as other decorators. 

Sue ： That’s right. 

Mary ： Ooooh, I see. And because we are using object composition, we get a whole lot more 
flexibility about how to mix and match condiments and beverages. Very smooth. 

Sue ： Yes, if we rely on inheritance, then our behavior can only be determined statically at 
compile time. In other words, we get only whatever behavior the superclass gives us or that we 
override. With composition, we can mix and match decorators any way we like... at runtime. 

Mary ： And as I understand it, we can implement new decorators at any time to add new 
behavior. If we relied on inheritance, we’d have to go in and change existing code any time we 
wanted new behavior. 

Sue: Exactly. 


Mary ： I just have one more question. If all we need to inherit is the type of the component, 
how come we didn’t use an interface instead of an abstract class for the Beverage class? 

Sue ： Well, remember, when we got this code, Starbuzz already had an abstract Beverage class. 
Traditionally the Decorator Pattern does specify an abstract component, but in Java, obviously, 
we could use an interface. But we always try to avoid altering existing code, so don’t “fix” it if 
the abstract class will work just fine. 
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decorator training 


New barista traiHing 

Make a picture for what happens when the order is for a 
“double mocha soy latte with whip” beverage. Use the menu 
to get the correct prices, and draw your picture using the 
same format we used earlier (from a few pages back): 


Q Whip calls cost() on N 


A First, we call cost() on the 
^ outmost decorator, Whip. 



''dlvk roast 


丁 WW 
a 






0 DarkRoast 

v returns its cost, 


Q Whip adds its total, 10 cents, 
to the result from Mocha, and 
returns the final result—$1.29. 


A Mocha adds its cost, 20 
^ cents, to the result from 
DarkRoast, and returns 
the new total, $1_19. 




- Coffin 

Coffees 
House Blend 
Dark Roast 
Decaf 
Espresso 


.89 
• 99 
.05 
.99 


Condiments 
Steamed Milk 
Mocha 

Soy 

Whip 


.10 

.20 

.15 

.10 
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the decorator pattern 

Writing the Starbozz code 

It’s time to whip this design into some real code. 

Let’s start with the Beverage class, which doesn’t need to 
change from Starbuzz’s original design. Let’s take a look: 


o 


public abstract class Beverage { 

String description = ''Unknown Beverage^ 

public String getDescription() { 




return description; 

} 

public abstract double cost(); 


ybPcsdvip-tio^ is already 
-fov us, ku-t wc 
*bo dos 七 0 

•m subclasses. 


Beverage is simple enough. Let’s implement the abstract 
class for the Condiments (Decorator) as well: 





public abstract class CondimentDecorator extends Beverage { 



public abstract String getDescription(); 



lA/cVc also -to vc<\u*ivc 

■that do 灼 dimctvt 


detova-tovs all "the 

ytDcsdV’iptiO 灼 0 method- 

we’ll see Y/Ky'm 3 set … 
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implementing the beverages 


Coding beverages 

Now that we’ve got our base classes out of the way ， let’s 
implement some beverages. We’ll start with Espresso. 
Remember, we need to set a description for the specific 
beverage and also implement the cost() method. 


public class Espresso extends Beverage { 


public Espresso() 
description = 

} 


''Espresso^ 


public double cost() 
return 1.99; 

} 





To take tave tV>e desCrH^ ^e 
set this'm the tonsirucior for the 
tlass. Re^er^bev the des4v.\>tior« mstar»de 
vaviable is inhevi-ted 心 ⑽ Bevevage- 


3 磁踩驗 F 


public class HouseBlend extends Beverage { 
public HouseBlend() { 

description = ''House Blend Coffee"; 

} 


public double cost() { 
return .89; 

} 


Okay, V>cv-c s 仏 ev Bcvcv-ay. All ^ 
do is sci tV>C apj?v-opv-iatc 
w t+ousc Blc^di av\d 代七狀灼 

60s 七:的 


You dvcatc 七 he o 七 her "two Bcvcvay dlassscs 

(PavkRoas-t a^d Pcda-f) m cx-a^-tly same way- 


Coffee 

S 2 ^ letld 

House Bie 

.89 

.99 

Dark Roast ^ 

.05 

Decaf 1 

l.99 

Espresso 


Steamed ^ 

.10 

.20 

Vlodha 

.15 

soy 

.10 

你 ip 
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Coding condiments 


the decorator pattern 


If you look back at the Decorator Pattern class diagram, you’ll 
see we’ve now written our abstract component (Beverage)，we 
have our concrete components (HouseBlend)，and we have our 
abstract decorator (CondimentDecorator). Now it’s time to 
implement the concrete decorators. Here’s Mocha: 


is a dcdova-tov, so wc 
C% 七 ⑺ d Cdoira*toV-. 






public class Mocha extends CondimentDecorator { 
Beverage beverage; 


public Mocha(Beverage beverage) { 
this.beverage = beverage; 


} 


public String getDescription() { 

return beverage.getDescription() + 

} 

public double cost() { 

return .20 + beverage.cost(); 

} xx 


c 。’ 办 

r 二 二 

(I) ' ,aviaWe 

、⑴ A 叫七。“七’吣心 

，二 ‘V。 如 



Mocha '， 




. \ 0 i.L^ £,os*t OUV bcvcv-ay 




V^lt wa»vt ouv dcsdviptioh "to hot ohly 
ihdude {\)t beverage - say w Pavk 
Roas*t w - but also -to include 
item dc^ovatmg the beverage, (or 
ihs-tah^c, w Davk Roas-t, tAocMd!*- So 
-Pivs-t delegate to tKc objedt y/c arc 
dedovatmg -to get its dcs^vip-tioh, -thcr» 
append w , /1/Iodha” to desdvip-tion. 


0 y \ the 於乂七 page well actually *ms*tah*tia*tc -the bevevage 

v/vap i*t with all i*ts dohdi 州 Civts (dcdova*tors) ; but 七 … 


^Y\d 



Write and compile the code for the other Soy and Whip 
condiments. You’ll need them to finish and test the application. 
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testing the beverages 


Serving some coffees 

Congratulations. It’s time to sit back, order a few coffees and marvel at 
the flexible design you created with the Decorator Pattern. 

Here’s some test code*to make orders: 


public class StarbuzzCoffee { 


0 二 ::；〆 




public static void main(String args[]) { ( __ 

Beverage beverage = new Espresso (); 

System.out.println(beverage.getDescription() 

+ '、$’’ + beverage. cost ()); 

Make a 

Beverage beverage2 = new DarkRoast () ; v/rth a Mo6n3- 

beverage2 = new Mocha(beverage2); ^ 

beverage2 = new Mocha(beverage2); 
beverage2 = new Whip(beverage2); <■ 


System.out.println(beverage2.getDescription() 
+ '' + beverage2 • cost ()); 


pavkRoast 七 . 


㈨ vap it ih a setohd /Vloiha. 
it ih a Whip. 


Beverage beverage3 = new HouseBlend(); 
beverage3 = new Soy(beverage3); 
beverage3 = new Mocha(beverage3); 
beverage3 = new Whip(beverage3); 

System.out.println(beverage3.getDescription() 
+ '、$’’ + beverage3 . cost ()); 


Fmally, 5We w a HouseBlend 
Soy, /Vlodha, a«d 


Now, let’s get those orders in: 


本 Wtrt jo'mj *to see d v/ay 

dv-catmj dedovated objedis wc dovcv 
Fa^-tory ?aiicyv\ (ar\A Buildcv Pattcv-h, 
^\\\cM is dovcvcd *m 七 he appendix.). 


1 File Edit Window Help CloudsInMvCoffee 


■ 

% java StarbuzzCoffee 

Espresso $1.99 

Dark Roast Coffee, Mocha, Mocha, Whip 
House Blend Coffee, Soy, Mocha, Whip 

% 

$1.49 

$1.34 
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the decorator pattern 


DumPc^uestiPiis 


I’m a little worried about code 
that might test for a specfic concrete 
component - say, HouseBlend - and 
do something, like issue a discount. 

Once I’ve wrapped the HouseBlend 
with decorators, this isn’t going to work 
anymore. 

That is exactly right. If you have 
code that relies on the concrete component’s 
type, decorators will break that code. 

As long as you only write code against 
the abstract component type, the use of 
decorators will remain transparent to your 
code. However, once you start writing code 
against concrete components, you’ll want to 
rethink your application design and your use 
of decorators. 


Wouldn’t it be easy for some 
client of a beverage to end up with 
a decorator that isn’t the outermost 
decorator? Like if I had a DarkRoast with 
Mocha, Soy, and Whip, it would be easy 
to write code that somehow ended up 
with a reference to Soy instead of Whip, 
which means it would not include Whip in 
the order. 

You could certainly argue that 
you have to manage more objects with 
the Decorator Pattern and so there is 
an increased chance that coding errors 
will introduce the kinds of problems you 
suggest. However, decorators are typically 
created by using other patterns like Factory 
and Builder. Once we’ve covered these 
patterns, you’ll see that the creation of the 
concrete component with its decorator is 
"well encapsulated” and doesn’t lead to 
these kinds of problems. 


Can decorators know about the 
other decorations in the chain? Say, I 
wanted my getDecription() method to 
print "Whip, Double Mocha” instead of 
“Mocha, Whip, Mocha ”？ That would 
require that my outermost decorator 
know all the decorators it is wrapping. 

Decorators are meant to add 
behavior to the object they wrap. When 
you need to peek at multiple layers into 
the decorator chain, you are starting to 
push the decorator beyond its true intent. 
Nevertheless, such things are possible. 
Imagine a CondimentPrettyPrint decorator 
that parses the final decription and can print 
“Mocha, Whip, Mocha” as "Whip, Double 
Mocha.” Note that getDecription() could 
return an ArrayList of descriptions to make 
this easier. 


- ^ jharpen your pencil 


Our friends at Starbuzz have introduced sizes to their menu. You can now order 


a coffee in tall, grande, and venti sizes (translation: small, medium, and large). 
Starbuzz saw this as an intrinsic part of the coffee class, so they’ve added two 
methods to the Beverage class: setSizeO and getSizeO- They’d also like for the 
condiments to be charged according to size, so for instance, Soy costs 100 ， 15^ 
and 20^ respectively for tall, grande, and venti coffees. 


How would you alter the decorator classes to handle this change in requirements? 
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decorators in java i/o 


Real World decorators: Java I/O 

The large number of classes in the java.io package is... overwhelming. Don’t feel alone 
if you said “whoa” the first (and second and third) time you looked at this API. But 
now that you know the Decorator Pattern, the 1/O classes should make more sense 
since the java.io package is largely based on Decorator. Here’s a typical set of 
objects that use decorators to add functionality to reading data from a file: 



L'mcNur»bcv|hpu*tS-tvcam i 
also a dgdoiratov 

It adds -the ability {o 

乙 ouirt the I'mc humbev-s as 

it v-cads data. 


bu^evs \^i io I^vovc 

a^a also au^m^ts 

i\^t a ^ 

^od rcadU^O U 
^Kavad-tcv-kascd a 
a 七 a Wc- 


忍 i(jQfej^t/InputStream and Z^we/VMm6erInputStream both extend 
Fi/terlnputStream, which acts as the abstract decorator class. 
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Pecoratiwg thejava.io classes 


the decorator pattern 



0 吖 






FilelnputStream 




T^csc l^pu-tS-tvcams ad*t bs 
七 he tor\Cxt\jt 七 ^ 七 

we v/ill dc6ov-a*tovs. 

T^cv-c av-c a -fcv/ move wc did^ *t 
showjike Objc^tl 呻 u*tS*brcam. 



Pil-tcv-kpu-tS-bvcaw 
is absVad 七 

dc^ov-a-tov. 


LineNumberlnputStream 


ZW -fmallv，all our to^rete d«^aU« 


You can see that this isn’t so different from the Starbuzz design. You should 
now be in a good position to look over thejava.io API docs and compose 
decorators on the various input streams. 

And you’ll see that the output streams have the same design. And you’ve 
probably already found that the Reader/Writer streams (for character-based 
data) closely mirror the design of the streams classes (with a few differences 
and inconsistencies, but close enough to figure out what’s going on). 

But Java I/O also points out one of the downsides of the Decorator Pattern: 
designs using this pattern often result in a large number of small classes 
that can be overwhelming to a developer trying to use the Decorator-based 
API. But now that you know how Decorator works, you can keep things in 
perspective and when you’re using someone else’s Decorator-heavy API, you 
can work through how their classes are organized so that you can easily use 
wrapping to get the behavior you’re after. 
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write your own i/o decorator 


Writing your oww Java I/O Pecorator 


Okay, you know the decorator Pattern, youVe 
seen the I/O class diagram. You should be ready to 
write your own input decorator. 

How about this: write a decorator that converts 
all uppercase characters to lowercase in the 
input stream. In other words, if we read in "1 


No problem. I just have to 
extend the FilterlnputStream class 
and override the read() methods. 


know the decorator Pattern therefore I RULE!" 
then your decorator converts this to 〃i know the 
decorator pattern therefore i rule!" 


产、 o... 、灼。 


pivsi, e%ie«d ihe P 技 crl 叶 <* 找 七代 ― 七 & 
absivati detovaW -fov all l^wtSivea^s. 



public class LowerCaselnputStream extends FilterlnputStream 
public LowerCaselnputStream(InputStream in) { 
super(in); 



} 


public int read() throws IOException { 
int c = super.read(); 

return (c == -1 ? c : Character.toLowerCase((char)c)); 


public int read(byte[] b, int offset, int len) throws IOException { 
int result = super•read(b, offset, len); 
for (int i = offset; i < offset+result; i++) { 

b[i] = (byte)Character.toLowerCase((char)b[i]); 

} vedd methods- TKcy a 

return result; by-tc (ov By\ avv-ay o-f bytes) 

} a^d do^vcvb caA byte 

a dKav-at'tcv') *to 

lov/cvdasc i-f its by\ u^fcvtasc 

dKava^W- 



R£/VI£mBER ： y/c do^-t fvovidc im^ovt ar»d fadkaje 
s-ta-tcmc^-b "tKc Code lis-t'mjs. -tKc Complete 
souvdc todt -fv-orw -tKc Kcad-fiv-s-tlabs y/cb site, you’ll 
■find "tKc URL oy\ pay x^ciii m "tKc livbro. 
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the decorator pattern 


Test out your new Java 1/0 decorator 

Write some quick code to test the 1/0 decorator: 


public class InputTest { 

public static void main(String[] args) throws IOException { 
int c; 
try { 

InputStream in = 

new LowerCaselnputStream( ^ 

new BufferedlnputStream( 

new FilelnputStream(''test • txt 〃）））； 


9£藏 


while((c = in.read()) >= 0) { 
System.out.print((char)c); 

} 

in.close (); 

} catch (IOException e) { 
e.printStackTrace(); 


Jus 七 use 七 he s-tv-carw to read 
utrtil 七 he cv\d o-f 
-f ile Bv\d p\rih*t 3s v/C go. 


扣 d ， _ 

Uo'UC'T 1 


Wad w 



test.txt file 


^ive it a spin: 




File Edit Window Help DecoratorsRule 


java InputTest 

.know the decorator pattern therefore i rule! 
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decorator interview 


Head First: Welcome Decorator Pattern. We’ve heard that you’ve been a bit 
down on yourself lately? 

Decorator ： Yes, I know the world sees me as the glamorous design pattern, but 
you know, I’ve got my share of problems just like everyone. 

HeadRrst: Can you perhaps share some of your troubles with us? 

Decorator ： Sure. Well, you know I’ve got the power to add flexibility to 
designs, that much is for sure, but I also have a dark side. You see, I can sometimes 
add a lot of small classes to a design and this occasionally results in a design 
that’s less than straightforward for others to understand. 

Head First: Can you give us an example? 

Decorator ： Take the Java 1/ O libraries. These are notoriously difficult for 
people to understand at first. But if they just saw the classes as a set of wrappers 
around an InputStream, life would be much easier. 

Head First: That doesn’t sound so bad. You’re still a great pattern, and 
improving this is just a matter of public education, right? 

Decorator ： There’s more, I’m afraid. I’ve got typing problems: you see, 
people sometimes take a piece of client code that relies on specific types and 
introduce decorators without thinking through everything. Now, one great thing 
about me is that can usually insert decorators transparently and 
the client never has to know it，s dealing with a decorator. But like I 
said, some code is dependent on specific types and when you start introducing 
decorators, boom! Bad things happen. 

HeadRrst: Well, I think everyone understands that you have to be careful 
when inserting decorators, I don’t think this is a reason to be too down on 
yourself. 

Decorator ： I know, I try not to be. I also have the problem that introducing 
decorators can increase the complexity of the code needed to instantiate the 
component. Once you’ve got decorators, you’ve got to not only instantiate the 
component, but also wrap it with who knows how many decorators. 

HeadRrst: I’ll be interviewing the Factory and Builder patterns next week — I 
hear they can be very helpful with this? 

Decorator ： That’s true; I should talk to those guys more often. 

Head First: Well, we all think you’re a great pattern for creating flexible designs 
and staying true to the Open-Closed Principle, so keep your chin up and think 
positively! 

Decorator: I’ll do my best, thank you. 


▼Pattern Bxposedi' 

This week’s interview: 
Confessions of a Decorator 
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Tools for your Pesigw Toolbox 

You’ve got another chapter under 
your belt and a new principle and 
pattern in the toolbox. 


a- 


00 Pv^# cs 

认一 V 、二必加 洗. 
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I 户弋 


V\/e y\o^i V^avc *tV\c 0\>c^-Closcd 
Pmdi ? le to rdc us. WcVc 
•to s-tv'ive -to desi 沪 OWT sys-tem 
so tV>aUV>e tlosed ?avts ave 
isolated ^vor« owv new e^teiasions. 
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BULLET POINTS 


Inheritance is one form of 
extension, but not necessarily 
the best way to achieve flexibility 
in our designs. 

In our designs we should allow 
behavior to be extended without 
the need to modify existing code. 

Composition and delegation 
can often be used to add new 
behaviors at runtime. 

The Decorator Pattern provides 
an alternative to subclassing for 
extending behavior. 

The Decorator Pattern involves 
a set of decorator classes that 
are used to wrap concrete 
components. 

Decorator classes mirror the 
type of the components they 
decorate. (In fact, they are the 
same type as the components 
they decorate, either through 
inheritance or interface 
implementation.) 

Decorators change the behavior 
of their components by adding 
new functionality before and/or 
after (or even in place of) method 
calls to the component. 

You can wrap a component with 
any number of decorators. 

Decorators are typically 
transparent to the client of the 
component; that is, unless 
the client is relying on the 
component’s concrete type. 

Decorators can result in many 
small objects in our design, and 
overuse can be complex. 
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Exercise solutions 


public class Beverage { 


// declare instance variables for milkCost, 

II soy Cost, mochaCost, and whipCost, and 
// getters and setters for milk, soy, mocha 
// and whip. 

public class DarkRoast extends Beverage { 


public DarkRoast() { 

public double cost() { 

description = ''Most Excellent Dark Roast"; 

double condimentCost = 0.0; 

) 

if (hasMilkO) { 

public double cost() { 

condimentCost += milkCost; 

} 

return 1.99 + super.cost(); 

if (hasSoyO) { 

condimentCost += soyCost; 

} 

if (hasMocha()) { 

condimentCost += mochaCost; 

} 

if (hasWhipO) { 

condimentCost += whipCost; 

} 

} 

/ 

return condimentCost; 

} 

} 




New barista training 



“double mocha soy latte with whip” 

Q Whip calls cost() on Mocha 

❺ Mocha calls cost() on another Mocha. 
First，we call cost() on the —— ■■ — * cos' 


irst, we can cosx \； … 
utmost decorator, Whip. 



Finally, the result returns to 
Whip’s cost(), which adds .10 and 
we have a final cost of $1.54. 


q Next, Mocha calls cost() on Soy. 

A Last topping! Soy calls 
^ cost() on HouseBlend. 

Q HouseBlencTs cost() 

^ method returns .89 
cents and pops off 
the stack. 

Q Soy，s cost() method 
adds .15 and returns 
the result, and pops 
off the stack. 

d The second Wlocha’s 
^ cost() method adds .20 
and returns the result, 
and pops off the stack. 

© The first Mochas cost() method 
adds .20 and returns the result, 
and pops off the stack. 
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Our friends at Starbuzz have introduced sizes to their menu. You can now order a coffee in 
tall, grande, and venti sizes (for us normal folk: small, medium, and large). Starbuzz saw this 
as an intrinsic part of the coffee class, so they’ve added two methods to the Beverage class: 
setSizeO and getSizeO. They’d also like for the condiments to be charged according to size, so 
for instance, Soy costs 10^, 15^, and 200 respectively for tall ， grande, and venti coffees. 

How would you alter the decorator classes to handle this change in requirements? 


public class Soy extends CondimentDecorator 
Beverage beverage; 

public Soy(Beverage beverage) { 

this.beverage = beverage; / 


public int getSize() { 

return beverage.getSize(); 

} 




At 




public String getDescription() { 

return beverage. getDescription () + ' 、， Soy"; 


public double cost() { 

double cost = beverage.cost (); 

if (getSize() == Beverage.TALL) { 々 

cost += .10; 

} else if (getSize() == Beverage.GRANDE) { 
cost += .15; 

} else if (getSize() == Beverage.VENTI) { 
cost += .20; 

} 

return cost; 


Hcvc wc sizjC (y/WiA 

all the >/ay *to the 
cor\txt\jt bcvcvajc) a^d {\\cy\ 
add appv-opvia-tc 乙 。 st 
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4 the Factor/ ?£tttern 



Baking with 00 Goodness 

w 



Get ready to bake some loosely coupled 00 designs. There is more to 
making objects than just using the new operator. You’ll learn that instantiation is an activity that 
shouldn’t always be done in public and can often lead to coupling problems. And you don’t want 
that, do you? Find out how Factory Patterns can help save you from embarrasing dependencies. 


this is a new chapter 
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thinking about new" 


Okay, it’s been three chapters 
and you still haven't answered my 
question about new. We aren't supposed 
to program to an implementation but 
every time I use new, that's exactly 
what I’m doing, right? 


O 



When you see “new”, think ^concrete”. 

Yes, when you use new you are certainly instantiating a concrete 
class, so that’s definitely an implementation, not an interface. And 
it’s a good question; you’ve learned that tying your code to a 
concrete class can make it more fragile and less flexible. 


Duck duck = new MallardDuck(); 







When you have a whole set of related concrete classes, often you’re 
forced to write code like this: 

Duck duck; 


if (picnic) { 

duck = new MallardDuck(); 
} else if (hunting) { 

duck = new DecoyDuck(); 

} else if (inBathTub) { 

duck = new RubberDuck(); 

} 


We have a WA d 七 

dut kdass e s,a«d^doak^ 


Here we’ve got several concrete classes being instantiated, and the 
decision of which to instantiate is made at runtime depending on 
some set of conditions. 

When you see code like this, you know that when it comes time for 
changes or extensions, you’ll have to reopen this code and examine 
what needs to be added (or deleted). Often this kind of code ends 
up in several parts of the application making maintenance and 
updates more difficult and error-prone. 
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the factory pattern 



What’s wrong with “new ”？ 

Technically there’s nothing wrong with new, after all, it’s a 
fundamental part of Java. The real culprit is our old friend 
CHANGE and how change impacts our use of new. 

By coding to an interface, you know you can insulate yourself 
from a lot of changes that might happen to a system down 
the road. Why? If your code is written to an interface, then 
it will work with any new classes implementing that interface 
through polymorphism. However, when you have code 
that makes use of lots of concrete classes, you’re looking for 



trouble because that code may have to be changed as new 
concrete classes are added. So, in other words, your code 
will not be “closed for modification.” To extend it with new 
concrete types, you’ll have to reopen it. 

So what can you do? It’s times like these that you can fall back 
on OO Design Principles to look for clues. Remember, our 
first principle deals with change and guides us to identify the 


广 ㈡ dcsi 3^s should 
Jp iolr Cx &wioh bu 士 

二;::心。，- 

Fte,r ^ +o„ a 


aspects that vary and separate them from what stays the same. 


How might you take all the parts of your application that instantiate concrete classes and 
separate or encapsulate them from the rest of your application? 
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Identifying the aspects that vary 

Let’s say you have a pizza shop, and as a cutting-edge pizza store 
owner in Objectville you might end up writing some code like this: 

Pizza orderPizza() { 

Pizza pizza = new Pizza (); 



pizza.prepare (); 
pizza.bake (); 
pizza.cut (); 
pizza.box (); 



^ Axibility, ^ally 
this io be ah abstv-adt dlass o^ 
'tvtcKadc ； bu-t wc Gr /七 divcd-tly 
eitKcv- ihosc. 


return pizza; 


But you need more than one type of pizza... 

So then you’d add some code that determines the appropriate type of pizza 
and then goes about making the pizza: 


Pizza 


orderPizza (String type) { 謂 ^ass'm^ m 

Pizza pizza; _^ -b^c of -b 

ovdicv-P'izi3- 


if (type • equals (''cheese ”）） { 


pizza 

=new CheesePizza(); 


} else if 

(type.equals (''greek^) { 


pizza 

=new GreekPizza(); 


} else if 

(type.equals (''pepperoni ’’） 

{ 

pizza 

} 

=new PepperoniPizza(); 



pizza.prepare (); 
pizza.bake (); 
pizza.cut (); 
pizza.box (); 
return pizza; 


Based Oh tte type <^p pi 如 , we 
十七 iH e 心 —a £oh^ e £ e dass 
a " d assi 3" ^ ihe piz^a i«sb«<；e 

紐必 ㈣ h 的 
has 七。相十 … Uhe Pi 如 ln i e ^ ate 


Ov\U >wc Kavc a Piiz4, wc ^>vc\>avc i-t 
(you k^oy/, voll -tKc doujK, ov\ -tKc 
sau^e add -tKc f dKccsc), 

■tKcn y/c bake it, du-t it artd box. i*t| 


EadK Piz^ subiyfc (CKccscPiz^, 

l/cg^icPizia, d) k^ov/s Kow "to 
\>v-c^>avc itscl-f. 


112 Chapter 4 




the factory pattern 


Pot the pressure is ow to add more pizza types 

You realize that all of your competitors have added a couple of trendy pizzas to 
their menus: the Clam Pizza and the Veggie Pizza. Obviously you need to keep 
up with the competition, so you’ll add these items to your menu. And you haven’t 
been selling many Greek Pizzas lately, so you decide to take that off the menu: 


., s HOt ^ 








Pizza orderPizza(String type) { 
Pizza pizza; 


if (type• equals (''cheese ’’）） { 
pizza = new CheesePizza(); 

} ej-co if_C-typc. cquala (^grcolc^)( 

- now QrQQkr j-sza () ; 

} else if (type • equals ( 、 'pepperoni 〃） 
pizza = new PepperoniPizza(); 

} else if (type • equals ( 、 'clam〃）{ 
pizza = new ClamPizza(); 

} else if (type• equals (''veggie ’’） { 
pizza 二 new VeggiePizza(); 

} 

pizza.prepare(); 
pizza.bake(); 
pizza.cut(); 
pizza.box (); 
return pizza; 




j Wat 心 cs . 

t 

W, '/ouW 
■to tW»s 


TWis is y/V^a-t v/c -to s-tay 

same. Fov ^os-t 'part, 
^vc^av'm^, dookmg, a^d 
a vcmamcd same 

-fov- ycav-s ycav-s. So, 

dor\’t ttis todc io 

jus 七桄 c •士 吖 crates cm. 


Clearly, dealing with which concrete class is instantiated is really messing up our 
orderPizzaO method and preventing it from being closed for modification. But now 
that we know what is varying and what isn’t, it’s probably time to encapsulate it. 
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encapsulate object creation 


Encapsulating object creation 


So now we know we’d be better off moving the object creation 
out of the orderPizzaO method. But how? Well, what 
we’re going to do is take the creation code and move it out 
into another object that is only going to be concerned with 
creating pizzas. 


f (type.equals (''cheese") ) { 
pizza = new CheesePizza(); 

} else if (type. equals ( 、 'pepperoni〃> 
pizza = new PepperoniPizza(); 

} else if (type.equals (''clam”> { 
pizza = new ClamPizza(); 

} else if (type.equals (''veggie") { 
pizza = new VeggiePizza(); 


Pizza orderPizza(String type) { 
Pizza pizza; 


pizza.prepare(), 
pizza.bake(); 
pizza.cut(); 
pizza.box(); 
return pizza; 


tvea-tio« tode ou-t ^ 

0 ^ e r?\^z3 




9oih 9 io 


3 ° 


r 二 r 二心 
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We’ve got a name for this new object: we 
call it a Factory. 


Factories handle the details of object creation. Once we have 
a SimplePizzaFactory, our orderPizzaO method just becomes a 
client of that object. Any time it needs a pizza it asks the pizza 
factory to make one. Gone are the days when the orderPizzaQ 



method needs to know about Greek versus Clam pizzas. Now 
the orderPizzaO method just cares that it gets a pizza, which 
implements the Pizza interface so that it can call prepareO, 
bakeQ, cutQ, and boxQ. 


We’ve still got a few details to fill in here; for instance，what does 
the orderPizzaO method replace its creation code with? Let’s 
implement a simple factory for the pizza store and find out... 
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building a simple pizza factory 


We’ll start with the factory itself. What we’re going to do is define a class that encapsulates the object 
creation for all pizzas. Here it is... 


Hcvcs ouv- 


orvc jol 


\) i 


1 心⑽ a 七 •• 吒 ? »z^s U '.ts d 咖 ts. 


public class SimplePizzaFactory { 


Mas 



public Pizza createPizza(String type) { 
Pizza pizza = null; 



if (type• equals (''cheese") ) { 


pizza 
else if 
pizza 
else if 
pizza 
else if 
pizza 


=new CheesePizza(); 

(type.equals (''pepperoni^)) 
=new PepperoniPizza(); 
(type• equals (''clam") ) { 

=new ClamPizza(); 

(type• equals (''veggie ’’）） { 
=new VeggiePizza(); 


return pizza; 



)Hffres tode ^ 

J ylutked owt 

1 饮如必』 meUod- 


This tode is still yava»etevi«d by 

thelike ou^r 
ovi^mdi ovdevPizza^ was. 


What’s the advantage of this? 

It looks like we are just pushing the 
problem off to another object. 

One thing to remember is that the 
SimplePizzaFactory may have many clients. 
We’ve only seen the orderPizza() method; 
however, there may be a PizzaShopMenu 
class that uses the factory to get pizzas 
for their current description and price. We 
might also have a HomeDelivery class that 
handles pizzas in a different way than our 


tiiimB e ^u©stipns 

PizzaShop class but is also a client of the 
factory. 

So, by encapsulating the pizza creating 
in one class, we now have only one 
place to make modifications when the 
implementation changes. 

Don’t forget, we are also just about to 
remove the concrete instantiations from our 
client code! 


I’ve seen a similar design where 
a factory like this is defined as a static 
method. What is the difference? 

Defining a simple factory as a 
static method is a common technique and 
is often called a static factory. Why use a 
static method? Because you don’t need 
to instantiate an object to make use of the 
create method. But remember it also has 
the disadvanage that you can’t subclass and 
change the behavior of the create method. 
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Reworking the PizzaStore class 

Now it’s time to fix up our client code. What we want to do is rely on the 
factory to create the pizzas for us. Here are the changes: 


Now y/c give Piz^aS-tovc a 
■to a Sim^lcPiz^Fad-tovy. 


public class PizzaStore { 

SimplePizzaFactory factory; 


public PizzaStore(SimplePizzaFactory factory) 
this.factory = factory; 



Pi^SW e geis ?assed io 

，h the dohstvud-tov-. 


public Pizza orderPizza(String type) { 
Pizza pizza; 


pizza = factory.createPizza(type); 

pizza.prepare(); 
pizza.bake(); 

pizza.cut (); A 

pizza.box(); I 

return pizza; I 


f[Y\d -k^c ovdcv-Piz^O wethod uses 
•fad-tov-Y bo trtait i-ts ^'iz^as by simply 
^ass'mg or\ ttc ■tY'pc o*f ov-dev-. 


// other methods here 


Kotidc v/eve vc^latcd ^ 

o\>^a-tov a ^ca-tc mc-t^od on 
^ad-tory object- No more do^c-tc 

msiar»-tiatior\S Vicv-c| 



这 一 


We know that object composition allows us to change behavior dynamically at runtime (among 
other things) because we can swap in and out implementations. How might we be able to use 
that in the PizzaStore? What factory implementations might we be able to swap in and out? 


(00} 'U8ABH M0N J06JOJ. }OU 

s,i0|) sauope^ Bzzjd 0|Ajs e!u」o 川 eo pue ‘o6eo!i|C) ‘>|JO 人 m0|s| 6u!>|u!lii 0J ( 0m \r\q ‘no 八 inoqe mou>| !‘uop eyy\ 
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The Simple Factory defined 

The Simple Factory isn’t actually a Design Pattern; it’s more of a programming idiom. 
But it is commonly used, so we’ll give it a Head First Pattern Honorable Mention. 
Some developers do mistake this idiom for the “Factory Pattern,” so the next time 
there is an awkward silence between you and another developer, you’ve got a nice 
topic to break the ice. 

Just because Simple Factory isn’t a REAL pattern doesn’t mean we shouldn’t check out 
how it’s put together. Let’s take a look at the class diagram of our new Pizza Store: 


Honorable 

Mention 



7 -the 

如 b c by tKc a^d 

handed bafik io -tKc 


Think of Simple Factory as a warm up. Next, we’ll explore two heavy duty patterns 
that are both factories. But don’t worry, there’s more pizza to come! 

决 Jusi a^o-tKcv vcm'mdcv -： m dcsij^ pa-t-tev-^s, -tKc fKvasc does MOT alv/ays 

w v/viic a dlass iKc a Java miev-fate, by us'mj iKc w impleme>vts’’ keyword m -tKc dlass dedavatioh.’’ 

iKc jchcv-al use of -tKc pKvasc, a toY\trc{x dass implcmch-t'mj a mc-tKod -fvom a supev-type (v/KidK dould be a 
dlass OR micv-fa^c) is still dohsidcv-cd io be iKc micv-fatc w of -tKai supertype. 


you are here 
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pizza franchise 


FraHchising the pizza store 

Your Objectville PizzaStore has done so well that you’ve trounced 
the competition and now everyone wants a PizzaStore in their 
own neighborhood. As the franchiser, you want to ensure the 
quality of the franchise operations and so you want them to use 
your time-tested code. 

But what about regional differences? Each franchise might 
want to offer different styles of pizzas (New York, Chicago, and 
California, to name a few), depending on where the franchise 
store is located and the tastes of the local pizza connoisseurs. 



y o u all -fvan^isc 02^3 stoves 

■to levevd^e youv P'.ziaS-torc todc, so 
art saw 叫 - 


O^t -fra^isc v/a^-Ua 
makes KV style 
七 Wm tr\Asi, iasbj saute and 
\us-t a little 


一 N -fv-a^isc 

y/dnis a fat 七 ov*Y Aa 七 
makes Ciiidago style 

^iz^as ； -tViciv tus-torwCV-s 

like ^>izi3s 
d.V'US't, vid-V^ s3udc ； 
iov\S of 


WeVe seen (me approach... 

If we take out SimplePizzaFactory and create three different 
factories, NYPizzaFactory, ChicagoPizzaFactory and 
CaliforniaPizzaFactory, then we can just compose the PizzaStore 
with the appropriate factory and a franchise is good to go. That’s 
one approach. 

Let’s see what that would look like... 
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Here v/c ^ca-tc a 
(or makmj KV s-tylc 

TKch v/c dveate a PiziaS-tovc a^d pass it 
a vc-fcvchdc to -the /V/ -fa^-tovy. 

、 - ahd wKch we make pizzas ； we 
jet N v /- S 'tylcd pizi^s. 

ChicagoPizzaFactory chicagoFactory = new ChicagoPizzaFactory(); 

PizzaStore chicagoStore = new PizzaStore(chicagoFactory); 
chicagoStore.order (''Veggie^); 


NYPizzaFactory nyFactory = new NYPizzaFactory(); 
PizzaStore nyStore = new PizzaStore(nyFactory); 
nyStore • order (''Veggie"); 



Likewise -fov- "the CKidajo piz^ s-fcoves ： we dveate 
a -fadiovy -fov- CKidago fizi^s a^d Cy-eaic a stove 
that is Composed v/i*tK a Chicago facioyy. l/VKeh 
we make pizzas, we get the CKidago -flavov-cd 
Ohes 


Put you'd like a little wore quality control 


So you test marketed the SimpleFactory idea, and what you 
found was that the franchises were using your factory to 
create pizzas, but starting to employ their own home grown 
procedures for the rest of the process: they’d bake things a 
little differently, they’d forget to cut the pizza and they’d use 
third-party boxes. 


I’ve been making pizza for 
years so I thought I’d add my 
own ''improvements” to the 
PizzaStore procedures... 


Rethinking the problem a bit, you see that what you’d really 
like to do is create a framework that ties the store and the 
pizza creation together, yet still allows things to remain 
flexible. 

In our early code, before the SimplePizzaFactory, we had 
the pizza-making code tied to the PizzaStore, but it wasn’t 
flexible. So, how can we have our pizza and eat it too? 


yja 仍七 a 5°°^ 

如 NOT 一七七 。 — 
Ua-t V>e ^ W,s ?，ZiaS ^r 


No 七山七 7 。《 

fv-ar\6Wisc. Vou 
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A framework for the pizza store 

There is a way to localize all the pizza making activities to the PizzaStore 
class, and yet give the franchises freedom to have their own regional style. 

What we’re going to do is put the createPizzaQ method back into PizzaStore, 
but this time as an abstract method, and then create a PizzaStore 
subclass for each regional style. 

First, let’s look at the changes to the PizzaStore: 


PiziaStovc is no>w abs-tva^t (see v/Ky below). 


public abstract class PizzaStore { 


public Pizza orderPizza(String type) { 
Pizza pizza; 


pizza = createPizza(type); 


Koy/ trcaicP'iz^a »s badk io bemg a 
dall to a rwciV^od m Piz^aS 七 ovc 

vat^cv ^ 3 ^ or\ a -fad-tovy object 


pizza.prepare (); 
pizza.bake(); 
pizza.cut (); 
pizza.box(); 

return pizza; 



All -t^is looks jus-t same -- 



abstract Pizza createPizza(String type); 

c 

0wr -»eihod M is h ow 

Piz^aSiov-e. 


we，v e -xoved out- fat-Uy 
objeti io this r»eihod. 


Now weVe got a store waiting for subclasses; we 5 re going to have a 
subclass for each regional type (NYPizzaStore, ChicagoPizzaStore, 
CaliforniaPizzaStore) and each subclass is going to make the decision about 
what makes up a pizza. Let’s take a look at how this is going to work. 
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Allowing the subclasses to decide 

Remember, the PizzaStore already has a well-honed order system in the orderPizzaQ 
method and you want to ensure that it’s consistent across all franchises. 

What varies among the regional PizzaStores is the style of pizzas they make — New York 
Pizza has thin crust, Chicago Pizza has thick, and so on - and we are going to push all 
these variations into the createPizzaO method and make it responsible for creating the 
right kind of pizza. The way we do this is by letting each subclass of PizzaStore define 
what the createPizzaO method looks like. So, we will have a number of concrete subclasses 
of PizzaStore, each with its own pizza variations, all fitting within the PizzaStore 
framework and still making use of the well-tuned orderPizzaQ method. 


PizzaStore 


createPizzaO 

orderPizza() 



fath subclass ovevvides iV>e dveaiePiziaO 
method, while all subclasses make wse 
d tV>e ovdevPi^O ^elVtod deemed 
m PizzaS-tove- I/'/e dowld make 
ovdevPiz^O meihod fmal 』 we veally 
wanted to ex-fovte 


a •fvaWise 'wairvb NV 
pizzas i-ts dus-tomev-s, it 
uses tv>e NV s>»btlass, V>as 

it o 训 tveatePi^aO method, 

tveatme NV style 


NYStylePizzaStore 

I 

ChicagoStylePizzaStore 1 

createPizzaO 


createPizzaO 


Remembev- tveateP.zzaO is 
abtvatt rn so all 

sieve sub 切 fes MUST 

implement tV>e «>etV>od- 


SimilavlY，by wsiinj iV>e 
Chitajo subtlass, we jet an 

tvea-tePi^O 
wiih CV>itay> ' 呼亡扣山 . 


I 


public Pizza createPizza(type) { 
if (type.equals (''cheese^) ) { 

pizza = new NYStyleCheesePizza(); 

} else if (type.equals (''pepperoni") { 
pizza = new NYStylePepperoniPizza(); 
} else if (type.equals (' 、 clam〃）{ 
pizza = new NYStyleClamPizza(); 

} else if (type.equals (''veggie"> { 
pizza = new NYStyleVeggiePizza(); 

} 

} 


public Pizza createPizza(type) { 
if (type.equals (''cheese") > { 

pizza = new ChicagoStyleCheesePizza(); 

(type.equals ( 、 'pepperoni 〃） { 
new ChicagoStylePepperoniPizza(); 
(type.equals ( 、 'clam〃> { 
new ChicagoStyleClamPizza(); 
(type.equals (''veggie") { 
new ChicagoStyleVeggiePizza(); 


} else if 
pizza 
} else if 
pizza 
} else if 
pizza 

} 


} 
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how do subclasses decide? 


I don’t get it. The 
PizzaStore subclasses are just 
subclasses. How are they deciding 
anything? I don’t see any logical decision-, 
making code in NYStylePizzaStore.. 


O 



Well, think about it from the point of view of the PizzaStore’s orderPizzaQ method: it is 
defined in the abstract PizzaStore, but concrete types are only created in the subclasses. 



土) : ㈣ 筱 叫 

.swbdass is att>*a"7 




Now, to take this a little further, the orderPizzaf) method does a lot of things with a 
Pizza object (like prepare, bake, cut, box), but because Pizza is abstract, orderPizzaO has 
no idea what real concrete classes are involved. In other words, it’s decoupled! 





When orderPizzaO calls createPizzaO, one of your subclasses will be called into action to 
create a pizza. Which kind of pizza will be made? Well, that’s decided by the choice of 
pizza store you order from, NYStylePizzaStore or ChicagoStylePizzaStore. 


NYStylePizzaStore 


ChicagoStylePizzaStore i 

createPizza() 


createPizza() 


So, is there a real-time decision that subclasses make? No, but from the perspective of 
orderPizzaO, if you chose a NYStylePizzaStore, that subclass gets to determine which 
pizza is made. So the subclasses aren’t really “deciding” - it was j ⑽ who decided by 
choosing which store you wanted — but they do determine which kind of pizza gets made. 
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the factory pattern 


Let§ make a PizzaStore 

Being a franchise has its benefits. You get all the PizzaStore 
functionality for free. All the regional stores need to do is subclass 
PizzaStore and supply a createPizza。method that implements 
their style of Pizza. We’ll take care of the big three pizza styles for 
the franchisees. 

Here’s the New York regional style: 






W/Piz^S-tovc cxichds 

Piz^S-tolrc, so i-t ihKcv-its 

o^ C «rPi 如 o ^iUod (a^ oi^s). 


public class NYPizzaStore extends PizzaStore { 
Pizza createPizza(String item) { 
if (item.equals (''cheese ”）） { 

return new NYStyleCheesePizza(); 

} else if (item.equals (''veggie ”）） { 
return new NYStyleVeggiePizza(); 

} else if (item.equals ( 、 'clam〃））{ 
return new NYStyleClamPizza(); 

} else if (item.equals ( 、 'pepperoni 〃）） { 

return new NYStylePepperoniPizza(); 
} else return null; 


^ 〜 .We’ve 30 七七。 i—cmetvt 
sindc it is 
abs-tv-ad-k m Piz^aS-tovc- 


ttcvVs v/Kcv-c y/c Create ouv- 
do^v-rtc dlasscs. Fov- eadK -type 
o-f Piz^a v/c dv-catc -the Ny s-tylc. 


决 Hoic tKat O\rdcv-pizia0 method m 
su^ev-dldss lids r\o dlue Piz^a >wc av-c 

jus 七 knows i-t tar\ \>vc^avc, bake, tu-t, and bo% it! 

Once we’ve got our PizzaStore subclasses built, it will be time 
to see about ordering up a pizza or two. But before we do that, 
why don’t you take a crack at building the Chicago Style and 
California Style pizza stores on the next page. 
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factory method 


: Sharpen your pencil 


We’ve knocked out the NYPizzaStore，just two more to go and we’ll be ready to franchise! 
Write the Chicago and California PizzaStore implementations here: 
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the factory pattern 


Peclariwg a factory method 


With just a couple of transformations to the PizzaStore we’ve gone from 
having an object handle the instantiation of our concrete classes to a set of 
subclasses that are now taking on that responsibility. Let’s take a closer look: 


public abstract class PizzaStore { 


public Pizza orderPizza(String type) { 

Pizza pizza; 

pizza = createPizza(type); 

pizza.prepare(); 
pizza.bake(); 
pizza.cut(); 
pizza.box(); 

return pizza; 

} 

protected abstract Pizza createPizza(String type) 
// other methods here 


Ue subtlasseso^ 

Pl «aSW £ ， dleoV) C 

■ ms “ 如十 乂： 


NYStylePizzaStore 

createPizza() 


ChicagoStylePizzaStore 

createPizza() 


/\|| i\^t vcs^o^sib»l»t7 ^ov 

Pizzas V>as bee« 
moved mto a metiiod 払 at 
atts as a (atW/. 



TJp Ol^se 


A factory method handles object creation and encapsulates it in 
a subclass. This decouples the client code in the superclass from 
the object creation code in the subclass. 





A (atWy 




\)t 


咖加心 — 冰 


abstract Product factoryMethod(String type) 


A f^to\ry method ' I 


Prod^U ad-tuallv seated- 
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ordering a pizza 


Let's see how it works: ordering pizzas with 
the pizza factory method 



So how do they order? 


First, Joel and Ethan need an instance of a PizzaStore. Joel needs to instantiate a 
ChicagoPizzaStore and Ethan needs a NYPizzaStore. 

With a PizzaStore in hand, both Ethan and Joel call the orderPizzaO method and pass 
in the type of pizza they want (cheese, veggie, and so on). 

To create the pizzas, the createPizzaO method is called, which is defined in the 
two subclasses NYPizzaStore and ChicagoPizzaStore. As we defined them, the 
NYPizzaStore instantiates a NY style pizza, and the ChicagoPizzaStore instantiates 
Chicago style pizza. In either case, the Pizza is returned to the orderPizzaO method. 

The orderPizzaO method has no idea what kind of pizza was created, but it knows it is 
a pizza and it prepares, bakes, cuts, and boxes it for Ethan and Joel. 
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nyPizzaStore.orderPizza(cheese ); 


o 


㈣ 工巧二 

darned ms\dc r^sl 


The orderPizza() method then calls the createPizza() 
method: 


o 


Pizza pizza 


createPizza (''cheese"); 


Rcmc^bcv-, dvcatcPi^O, i\\t -fad-tov-y 
rnc-tKod, is •• 叶 Ic 你 ctvtcd m the subclass. \r\ 
tKis dasc it rctu\Ths a NV CKccsc Piz^a . 、 




Finally we have the unprepared pizza in hand and the 
orderPizza() method finishes preparing it: 


pizza.prepare (); 
pizza.bake(); 
pizza.cut(); 
pizza.box(); 、 - 


TV,e melV>od ^ 

WkaP, …減 'TT 
e %at«V towek 加 1 七， s . 


籼 乂枉仪 ">^ods a« d^d 

Worn ^ method 

^eaieP'.z^aO, deVmed m the 
l^yp'iziaS-borc- 


Pizza 


the factory pattern 


Let's check out how these pizzas are 
really made to order.. 


Beliind 
the Scene 



o 


❾ 


Let’s follow Ethan’s order: first we need a NY PizzaStore: 

PizzaStore nyPizzaStore = new NYPizzaStore(); 


Creaies a ihs-ta^c of 
"/Piz^SW - 


Now that we have a store, we can take an order: 


V/ 2ZI 


aS^ 


Qj 


,、essq3LSZJdssJO 
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the pizza classes 


WeYejust missing one thing: PIZZA! 


Our PizzaStore isn't going to be very popular 
without some pizzas, so let's implement them: 




public abstract class Pizza { 
String name; 

String dough; 

String sauce; 



UtV Pi 山 W a 一 e, a J a 

i^ c o-f saute, and a set d 


ArrayList toppings = new ArrayList(); 


void prepare() { 

System, out .println (''Preparing '' + name); 

System, out .println (''Tossing dough. 

System, out .println (''Adding sauce. 

System. out. println (''Adding toppings : '、）； 
for (int i = 0; i < toppings.size (); i++) { 

System. out. println ('' '、+ toppings . get (i)); 

} 


void bake() { 


r 

abs 七 vat 七 dlass povides 
some basit defaults -fov bakm 少 
du 七七叫 and \>o%\^. 

V 

pv-C^3v3t»o^ follov^ d 

^umbev- of s-tc^s m a 
?art» 〜 sc«\ucy»e.c- 


System, out .println (''Bake for 25 minutes at 350 〃）； 


void cut () { 

System, out .println (''Cutting the pizza into diagonal slices"); 


void box() { 

System, out .println (''Place pizza in official PizzaStore box 〃）； 


public String getName() { 
return name; 


v/c & oy !{. fvovidc im^ovt m -tKc 

todt listmjs. 6{t{, -tKc Complete souvdc todt -fvom -tKc Kcad-fiv-s-tlabs 
v/cb si-tc. yWlI -find -tKc URL oy \ \y\ -tKc livbro. 
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the factory pattern 


Now we just need some concrete subclasses... how about defmmg 
New York and Chicago style cheese pizzas? 


KY Pizza V^as its 

public class NYStyleCheesePizza extends Pizza { 
public NYStyleCheesePizza() { 

name = ''NY Style Sauce and Cheese Pizza 〃； 
dough = ''Thin Crust Dough 〃； 
sauce = ''Marinara Sauce^; 




州 armaa s 切 le saw ad ^ust- 


toppings . add (''Grated Reggiano Cheese"); 




Ay\d 


^°PP ih 3 - 代 33 如 0 iheese/ 


public class ChicagoStyleCheesePizza extends Pizza { 
public ChicagoStyleCheesePizza() { 

name = ''Chicago Style Deep Dish Cheese Pizza" 
dough = ''Extra Thick Crust Dough 〃； 
sauce = ''Plum Tomato Sauce"; 



The CUay> ?'^ ^ 
Watoes as a sawte aUg 
W.tV> e%tva Uitk tv-ust 


toppings . add (''Shredded Mozzarella Cheese 〃）； 


void cut() { 

System, out .printIn (''Cutting the pizza into square 


— The CKi^ago s-fcy| c d ccp 
dish piz^ Kas lo-ts o-f 

^oz^vclla ^Kccsc/ 

slices"); 



TKc CKitajo style fiz^a also ovcv-yidcs -tV^c 〜七 0 
method so -k^c \>icdcs arc mto smarts. 
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make some pizzas 


YooVe waited lovig enough, time for some pizzas! 


public class PizzaTestDrive { 

public static void main(String[] args) { 

PizzaStore nyStore = new NYPizzaStore(); 

PizzaStore chicagoStore = new ChicagoPizzaStore(); 


Pizza pizza = nyStore • orderPizza (''cheese"); 

System, out .printIn (''Ethan ordered a '、+ pizza. getName () + 









use or\t or\C s*tovc 
{jo make E-t^a^s order. 


l '\n"> ; 


pizza = chicagoStore.orderPizza (''cheese ,/ ); 

System, out .print In (''Joel ordered a '、+ pizza. getName () + 、 '\n ’’）； 


^ , 

J\^d o-tV^cv- -fov- Joel s. 


File Edit Window Help YouWantMootzOnThatPizza? 


% java PizzaTestDrive 

Preparing NY Style Sauce and Cheese Pizza 
Tossing dough... 

Adding sauce... 

Adding toppings : 

Grated Regiano cheese 
Bake for 25 minutes at 350 
Cutting the pizza into diagonal slices 
Place pizza in official PizzaStore box 
Ethan ordered a NY Style Sauce and Cheese Pizza 

Preparing Chicago Style Deep Dish Cheese Pizza 
Tossing dough... 

Adding sauce... 

Adding toppings : 

Shredded Mozzarella Cheese 
Bake for 25 minutes at 350 
Cutting the pizza into square slices 
Place pizza in official PizzaStore box 
Joel ordered a Chicago Style Deep Dish Cheese Pizza 


BotV> 户灿沪七 yveyaved, 

七 added, arvd 

?12 ^s baked, a«a bo^ed. 
Ouv suyevtlass rvevev V>ad to 
k_ ^ details, -tV.e subdass 

hailed all tv.at by 

■ mS tarvt.atm5 -tv>e 叫 k ? ,zza - 
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the factory pattern 


Ifs finally time to meet the Factory Method Pattern 


All factory patterns encapsulate object creation. The Factory Method Pattern encapsulates 
object creation by letting subclasses decide what objects to create. Let’s check out these class 
diagrams to see who the players are in this pattern: 


The Creator classes 


2 s is ,r 


匕 I 收 ， t de*Pi 


v ，hCS ▲■brad 
^<>d iUai 
subdasscs i 0 


PizzaStore 


createPizza() 

orderPizza() 



0-ftcn dveatov- don-b'ms todt 
deytr^ds on an abs-tvad-t pvodudt, 
is ^voduded by d subtldss. 丁 dv*c3"to^ 
y\^cr vcally knows dondvrtc 
^v-oduC."t >was ^vodi^ded- 


Smtc tat\\ WaMst y-U its 
oym subclass of P'lZiaS-tovc, 
iVs -fvee "to 6vc3*tc >"ts 

ovm style ?•> 以 W 

⑽ a 七 cP»z^a(). 





NYPizzaStore 

1 

ChicagoPizzaStore 

createPizza() 


createPizza() 


\ f 

Classes 

^od«t-b ave talkd 
to wte tveaWs 


The Product classes 


TKcsc avc i\\t dondvctc 
^v-odud-ts - all \>izias t^a-t 

avc ^v-oduded by ouv- stoves, p 



Pizza 


Pat-tov'ics ^v-odutc ^vod»Ad-ts, 
ad m 如 PlizaS-torc, ouv 
^vod'Ad'b > s 3 P>zi3- 


NYStyleCheesePizza 


NYStylePepperoniPizza 


ChicagoStyleCheesePizza [ 


NYStyleClamPizza 


ChicagoStylePepperoniPizza [ 


NYStyleVeggiePizza 


ChicagoStyleClamPizza 


ChicagoStyleVeggiePizza 
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creators and products 


Another perspective: parallel class hierarchies 

We’ve seen that the factory method provides a framework by supplying an 
orderPizzaO method that is combined with a factory method. Another way to look 
at this pattern as a framework is in the way it encapsulates product knowledge into 
each creator. 

Let’s look at the two parallel class hierarchies and see how they relate: 


P 

The Product classes 


Pizza 


NYStyleCheesePizza L 


NYStylePepperoniPizza 1 



NYStyleClamPizza { 




NYStyleVeggiePizza 






Notice Kov/ tKcsc 
dlass Kicv-av^Kics art 
pav-allcl ： bo-tK Have 
absiv-adt dlasses -tKat 
av-c by 

toy\trcit dlasses, y/KidK 
know about sy>cdi-fid. 
implcmcivtatiohs -fov- 
dnd CKidajo. 



The Creator classes 


PizzaStore 


createPizza() 

orderPizza() 


ChicagoStyleCheesePizza L 


ChicagoStylePepperoniPizza 1 



ChicagoStyleClamPizza 




ChicagoStyleVeggiePizza 



! 


NYPizzaStore 


ChicagoPizzaStore 


createPizza() 


createPizza() 







Ue (siior'l 






•to e«ta— 


■tv、s kr\OYi\cdy- 
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the factory pattern 



Design Puzzle 


We need another kind of pizza for those crazy Californians (crazy in a good way 
of course). Draw another parallel set of classes that you’d need to add a new 
California region to our PizzaStore. 





Okay, now write the five most bizarre things you can think of to put on a pizza. 
Then, you’ll be ready to go into business making pizza in California! 
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factory method defined 


Factory Method Pattern defined 

It’s time to roll out the official definition of the Factory Method Pattern: 


The Factory Method Pattern defines an interface 
for creating an object, but lets subclasses decide which 
class to instantiate. Factory Method lets a class defer 
instantiation to subclasses. 


As with every factory, the Factory Method Pattern gives us a way to encapsulate the 
instantiations of concrete types. Looking at the class diagram below, you can see that the 
abstract Creator gives you an interface with a method for creating objects, also known as the 
“factory method.” Any other methods implemented in the abstract Creator are written to 
operate on products produced by the factory method. Only subclasses actually implement 
the factory method and create products. 

As in the official definition, you’ll often hear developers say that the Factory Method lets 
subclasses decide which class to instantiate. They say “decides” not because the pattern 
allows subclasses themselves to decide at runtime, but because the creator class is written 
without knowledge of the actual products that will be created, which is decided purely by 
the choice of the subclass that is used. 










t\ass. 
V 


Product 


Creator 



factory Method ^_ 

anOperation() 








2 


ConcreteProduct 

< - 

ConcreteCreator 



factoryMethod() 


V 
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TKc abs-tvad-t (atbo^Mti\\odO 
is y/V^ai all Cvcaiov- subclasses 
mus-b 
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the factory pattern 


tiiifnB e ^u©stiPiis 

What’s the advantage of the Factory Method 
Pattern when you only have one ConcreteCreator? 

The Factory Method Pattern is useful if 
you’ve only got one concrete creator because you are 
decoupling the implementation of the product from 
its use. If you add additional products or change a 
product’s implementation, it will not affect your Creator 
(because the Creator is not tightly coupled to any 
ConcreteProduct). 


We implemented what is known as the 
parameterized factory method. It can make more than 
one object based on a parameter passed in, as you 
noticed. Often, however, a factory just produces one 
object and is not parameterized. Both are valid forms 
of the pattern. 

Your parameterized types don’t seem "type- 
safe." I’m just passing in a String! What if I asked for 
a “CalmPizza ”？ 


Would it be correct to say that our NY and 
Chicago stores are implemented using Simple 
Factory? They look just like it. 

They’re similar, but used in different ways. Even 
though the implementation of each concrete store looks 
a lot like the SimplePizzaFactory, remember that the 
concrete stores are extending a class which has defined 
createPizza() as an abstract method. It is up to each 
store to define the behavior of the createPizza() method. 
In Simple Factory, the factory is another object that is 
composed with the PizzaStore. 

Are the factory method and the Creator 
always abstract? 

No, you can define a default factory method 
to produce some concrete product. Then you always 
have a means of creating products even if there are no 
subclasses of the Creator. 


Each store can make four different kinds 
of pizzas based on the type passed in. Do all 
concrete creators make multiple products, or do they 
sometimes just make one? 


You are certainly correct and that would cause, 
what we call in the business, a “runtime error." There 
are several other more sophisticated techniques that 
can be used to make parameters more “type safe” ， or, 
in other words, to ensure errors in parameters can be 
caught at compile time. For instance, you can create 
objects that represent the parameter types, use static 
constants, or, in Java 5, you can use enums. 

I’m still a bit confused about the difference 
between Simple Factory and Factory Method. They 
look very similar, except that in Factory Method, the 
class that returns the pizza is a subclass. Can you 
explain? 

You’re right that the subclasses do look a lot 
like Simple Factory, however think of Simple Factory 
as a one shot deal, while with Factory Method you are 
creating a framework that let’s the subclasses decide 
which implementation will be used. For example, the 
orderPizza() method in the Factory Method provides a 
general framework for creating pizzas that relies on a 
factory method to actually create the concrete classes 
that go into making a pizza. By subclassing the 
PizzaStore class, you decide what concrete products 
go into making the pizza that orderPizza() returns. 
Compare that with SimpleFactory, which gives you a 
way to encapsulate object creation, but doesn’t give 
you the flexibility of the Factory Method because there 
is no way to vary the products you’re creating. 
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master and student 


Master and Student" 

Master: Grasshopper, tell me how your training is going? 

Student: Master, I have taken my study of "encapsulate what 
varies” further. 

Master: Go on... 

Student: I have learned that one can encapsulate the code that 
creates objects. When you have code that instantiates concrete 
classes, this is an area of frequent change. I’ve learned a 
technique called “factories” that allows you to encapsulate this 
behavior of instantiation. 

Master: And these “factories,” of what benefit are they? 

Student: There are many. By placing all my creation code in one 
object or method, I avoid duplication in my code and provide one 
place to perform maintenance. That also means clients depend 
only upon interfaces rather than the concrete classes required to 
instantiate objects. As I have learned in my studies, this allows me 
to program to an interface, not an implementation, and that makes 
my code more flexible and extensible in the future. 

Master: Yes Grasshopper, your 00 instincts are growing. Do 
you have any questions for your master today? 

Student: Master, I know that by encapsulating object creation 
I am coding to abstractions and decoupling my client code from 
actual implementations. But my factory code must still use 
concrete classes to instantiate real objects. Am I not pulling the 
wool over my own eyes? 

Master: Grasshopper, object creation is a reality of life; we must 
create objects or we will never create a single Java program. But, 
with knowledge of this reality, we can design our code so that we 
have corralled this creation code like the sheep whose wool you 
would pull over your eyes. Once corralled, we can protect and 
care for the creation code. If we let our creation code run wild, 
then we will never collect its “wool.” 

Student: Master, I see the truth in this. 

Master: As I knew you would. Now, please go and meditate on 
object dependencies. 
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the factory pattern 


A very dependent PizzaStore 


cr^rpen your pencil 


Let’s pretend you’ve never heard of an OO factory. Here’s a version of the PizzaStore that 
doesn’t use a factory; make a count of the number of concrete pizza objects this class is 
dependent on. If you added California style pizzas to this PizzaStore, how many objects would it 
be dependent on then? 


public class DependentPizzaStore { 


public Pizza createPizza(String style, String type) { 
Pizza pizza = null; 
if (style.equals ( 、 'NY〃））{ 

if (type.equals ( 、 'cheese 〃）） { 


pizza 
else if 
pizza 
else if 
pizza 
else if 
pizza 


=new NYStyleCheesePizza(); 
(type.equals (''veggie") ) { 

=new NYStyleVeggiePizza(); 
(type • equals ( 、 'clam 〃）） { 

=new NYStyleClamPizza(); 

(type.equals (''pepperoni^) ) { 

=new NYStylePepperoniPizza(), 




all NV 

style 


else if (style • equals ( 、 'Chicago〃> ) 
if (type.equals ( 、 'cheese 〃）） { 


pizza 
else if 
pizza 
else if 
pizza 
else if 
pizza 


=new ChicagoStyleCheesePizza () 
(type.equals ( 、 'veggie 〃）） { 

=new ChicagoStyleVeggiePizza() 
(type • equals ( 、 'clam 〃）） { 

=new ChicagoStyleClamPizza(); 
(type.equals (''pepperoni’'））{ 

=new ChicagoStylePepperoniPizza () 




Handles all 
CWitay> st/U 


else { 

System, out .printIn (''Error : 
return null; 


invalid type of pizza"); 


pizza.prepare() 
pizza.bake(); 
pizza.cut(); 
pizza.box(); 
return pizza; 


V^ou dart y/vi-tc 
youv at^sy/ers Kcrc ： 
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object dependencies 


Looking at object dependencies 

When you directly instantiate an object, you are depending on its 
concrete class. Take a look at our very dependent PizzaStore one 
page back. It creates all the pizza objects right in the PizzaStore class 
instead of delegating to a factory. 

If we draw a diagram representing that version of the PizzaStore 
and all the objects it depends on, here’s what it looks like: 


ihe oT 1L 


This vcvsioy> of {Mt 
PizxaS-tov-c depends on all 
•those ^>iz^a objects, bcdausc 
its "tKcm div-c^-tly. 



Bcdausc a^y to dondvctc 

r iw^lcrwcn-tations of pizzas a-f-fct'U tKc 
Piz^aS-to\rc, >wc say i\\ai i\\t Piz^aSWc 
w dc\>c^ds \>iz^a im\>lcmcniations. 
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the factory pattern 


The Pepewdewcy Inversion Principle 


It should be pretty clear that reducing dependencies to 
concrete classes in our code is a “good thing.” In fact, we’ve 

got an OO design principle that formalizes this notion; it even v^ oVA 63^ 

has a big, formal name: Dependency Inversion Principle. 

wse b 勹）。 〆. 


Here’s the general principle: 




Design Principle 

Depend upon abstractions. Do not 
depend upon concrete classes. 




At first, this principle sounds a lot like “Program to an 
interface, not an implementation, 55 right? It is similar; 
however, the Dependency Inversion Principle makes an even 
stronger statement about abstraction. It suggests that our 
high-level components should not depend on our low-level 
components; rather, they should both depend on abstractions. 

But what the heck does that mean? 

Well, let’s start by looking again at the pizza store diagram 
on the previous page. PizzaStore is our “high-level 
component” and the pizza implementations are our “low- 
level components，’’ and clearly the PizzaStore is dependent 
on the concrete pizza classes. 

Now, this principle tells us we should instead write our code 
so that we are depending on abstractions, not concrete 
classes. That goes for both our high level modules and our 
low-level modules. 



t VijK-lcvcl w is a tlass 

y,i-tK bcKaviov defined m -tcv-ms 


► 从饮 , W |o>w level” 

Fov PiziaSWc is a 

because 

i*ts bcKaviov is defined m "tcv-ms 

o*f pizzas - i 七 dveates all 
fiz^a objects, 

bakes, duls, and bo%cs 七 hem, 

七 he it uses av-c loy/-lcvcl 


But how do we do this? Let’s think about how we’d 
apply this principle to our Very Dependent PizzaStore 
implementation... 
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dependency inversion principle 


Applying the Principle 

Now, the main problem with the Very Dependent PizzaStore is that it depends 
on every type of pizza because it actually instantiates concrete types in its 
orderPizzaO method. 

While we’ve created an abstraction, Pizza, we’re nevertheless creating concrete 
Pizzas in this code, so we don’t get a lot of leverage out of this abstraction. 

How can we get those instantiations out of the orderPizzaO method? Well, as 
we know, the Factory Method allows us to do just that. 


So, after we’ve applied the Factory Method, our diagram looks like this: 


P»2^ is ar» absi\r3di 
dass... ^ absi ^jio^ ^ 


l 

0 


P' lzi aSto« oA'i 

on Piz^, -tV, e ab^at-b dass. 



dasses ^ 

^ 1 + P'.«^ .mtedate (v-emembev, 

Y/CVC USWj 
scr^sc) 




After applying the Factory Method, you’ll notice that our high-level component, 
the PizzaStore, and our low-level components, the pizzas, both depend on Pizza, 
the abstraction. Factory Method is not the only technique for adhering to the 
Dependency Inversion Principle, but it is one of the more powerful ones. 
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咎 


Where’s the “inversion” in Dependency 
Inversion Principle? 

The “inversion” in the name Dependency Inversion 
Principle is there because it inverts the way you 
typically might think about your OO design. Look 
at the diagram on the previous page, notice that the 
low-level components now depend on a higher level 
abstraction. Likewise, the high-level component 
is also tied to the same abstraction. So, the top-to- 
bottom dependency chart we drew a couple of pages 
back has inverted itself, with both high-level and low- 
level modules now depending on the abstraction. 

Let’s also walk through the thinking behind the typical 
design process and see how introducing the principle 
can invert the way we think about the design... 
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invert your thinking 


Inverting your thinking. 


。0 



Hmmm, Pizza Stores prepare, bake and 
box pizzas. So, my store needs to be 
able to make a bunch of different 
pizzas ： CheesePizza, VeggiePizza, 
ClamPizza, and so on... 




Okay，so you need to implement a PizzaStore. 
What’s the first thought that pops into your head? 


Right, you start at top and follow things down to 
the concrete classes. But, as you’ve seen, you don’t 
want your store to know about the concrete pizza 
types, because then it’ll be dependent on all those 
concrete classes! 

Now, let’s “invert” your thinking... instead of 
starting at the top, start at the Pizzas and think 
about what you can abstract. 


Right! You are thinking about the abstraction 
Pizza. So now, go back and think about the design 
of the Pizza Store again. 


Close. But to do that you’ll have to rely on a 
factory to get those concrete classes out of 
your Pizza Store. Once you’ve done that, your 
different concrete pizza types depend only on an 
abstraction and so does your store. We’ve taken 
a design where the store depended on concrete 
classes and inverted those dependencies (along 
with your thinking). 
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A few guidelines to help you follow the 
Principle... 


The following guidelines can help you avoid OO designs that violate 
the Dependency Inversion Principle: 

■ No variable should hold a reference to a concrete class. 


Wse 


■ No class should derive from a concrete class. 


\jo\A dcv-Wc (rom a dass ， 

youVc ot\ a tomtit tUss. 

P cv .,vc 心。 眯 a” abs-tradt'io^, like 
or abs-tvadt dass. 


No method should override 
any of its base classes. 


an implemented memoa oi 




But wait, aren't these 
guidelines impossible to follow? 
If I follow these, I’ll never be 
able to write a single program! 


You’re exactly right! Like many of our principles, this is a guideline 
you should strive for, rather than a rule you should follow all the time. 
Clearly, every single Java program ever written violates these guidelines! 





But, if you internalize these guidelines and have them in the back of 
your mind when you design, you’ll know when you are violating the 
principle and you’ll have a good reason for doing so. For instance, if you 
have a class that isn’t likely to change, and you know it, then it’s not the 


end of the world if you instantiate a concrete class in your code. Think 
about it; we instantiate String objects all the time without thinking twice. 
Does that violate the principle? Yes. Is that okay? Yes. Why? Because 
String is very unlikely to change. 

If, on the other hand, a class you write is likely to change, you have some 
good techniques like Factory Method to encapsulate that change. 
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families of ingredients 


Meanwhile, back at the FizzaStore 


The design for the PizzaStore is really shaping up: it’s got a 

flexible framework and it does a good job of adhering to Pova 分 



design principles. 

Now, the key to Objectville Pizza’s success has 
always been fresh, quality ingredients, and 
what you’ve discovered is that with the 
new framework your franchises have been 
following your procedures^ but a few franchises 
have been substituting inferior ingredients 
in their pies to lower costs and increase 
their margins. You know you’ve got to do 
something, because in the long term this is 
going to hurt the Objectville brand! 


Ensuring consistency iw your 
ingredients 

So how are you going to ensure each franchise is using 
quality ingredients? You’re going to build a factory that 








produces them and ships them to your franchises! 


Now there is only one problem with this plan: the franchises are located in 
different regions and what is red sauce in New York is not red sauce in Chicago. 
So, you have one set of ingredients that need to be shipped to New York and a 
different set that needs to shipped to Chicago. Let’s take a closer look: 



Chicago 

\zzaWena 


Cheese Pizza 

Plum Tomato Sauce, Mozzarella, Parmesan, 
Oregano 

Veggie Pizza 

Plum Tomato Sauce, Mozzarella, Parmesan, 
Eggplant Spinach, Black Olives 

Clam Pizza 川 

Plum Tomato Sauce, Mozzarella, Parmesan, Clams 

Pepperoni Pizza 

Plum Tomato Sauce, Mozzarella, Parmesan, 
Eggplant Spinach, Black Olives, Pepperom 


iVcvc 30 七七 he 
same pvodud 七 
-families (dou^, 

veggies, meats) 
bu 七 

i»v»flcmCy\-tations 

based or\ vcjion. 



Veggie Pizza 

Mahnaya Sauce, Reggiano, Mushrooms, 
Onions, Red Peppers 

Clam Pizza 

Marinara Sauce, Re 的 iano. Fresh Clams 
Pepperoni Pizza 

Marmara Sauce, Reggiano, Mushrooms, 
Onions, Rea Peppers, Peppemni 
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Families of ingredients.. 


New York uses one set of 
ingredients and Chicago another. 
Given the popularity of Objectville 
Pizza it won’t be long before you 
also need to ship another set of 
regional ingredients to California, 
and what’s next? Seattle? 

For this to work, you are going to 
have to figure out how to handle 
families of ingredients. 


Chicago 


FrozenClams 




i 

PlumTomatoSauce 

I 

ThickCrustDough 


1 


I 


MozzarellaCheese 


New York 


FreshClams 


MarinaraSauce 

| 

ThinCrustDough 



1 


ReggianoCheese 


Bsdh -family donsis-ts of a tyyc o( dougK, 
a o( saude ； a -ty^c o( and a 

sca+ood (alon^ witK a -few move >wc 

like vcjjics and slides). 


, ,A t saw 


California 


Calamari 



BruschettaSauce L 

VeryThinCrust 


1 

1 




GoatCheese 




you are here ► 145 








ingredient factories 


building the ingredient factories 

Now we’re going to build a factory to create our ingredients; the 
factory will be responsible for creating each ingredient in the 
ingredient family. In other words, the factory will need to create 
dough, sauce, cheese, and so on... You’ll see how we are going to 
handle the regional differences shortly. 

Let’s start by defining an interface for the factory that is going to 
create all our ingredients: 


public interface PizzalngredientFactory { 


public 

public 

public 

public 

public 

public 


Dough createDough(); 
Sauce createSauce(); 



Cheese createCheese()/ 
Veggies[] createVeggies(); 
Pepperoni createPepperoni(); 
Clams createClam(); 


: ：二 ㈣ 二 


Lots ^ tbsscs V^cvc, 
or\t myed • 丨 ⑶ t 


|-f >wcdi V>ad some do 你祕 U m36Wcv-Y 

to rn \^tt cA 

toM V^avc made tW»s 

abs-bv-att tlass ms-bcad -- 


Here’s what we’re going to do: 


❶ 


Build a factory for each region. To do this, you’ll create a subclass of 
PizzalngredientFactory that implements each create method 


❻ 

❺ 


Implement a set of ingredient classes to be used with the factory, like 
ReggianoCheese, RedPeppers, and ThickCrustDough. These classes can be 
shared among regions where appropriate. 

Then we still need to hook all this up by working our new ingredient 
factories into our old PizzaStore code. 
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Puildiwg the New York ingredient factory 


Okay, here’s the implementation for 
the New York ingredient factory. This 
factory specializes in Marinara sauce, 
Reggiano Cheese, Fresh Clams... 


The NV 

七 he mtev^ate ^ov all mjvediein-t 
•fat 七 ovies 


public class NYPizzalngredientFactory implements PizzalngredientFactory { 


public Dough createDough() { 

return new ThinCrustDough(), 

} 

public Sauce createSauce() { 

return new MarinaraSauce(); 






public Cheese createCheese() { 
return new ReggianoCheese(); 


public Veggies[] createVeggies() { 

Veggies veggies[] = { new Garlic() 
return veggies; 

} 

public Pepperoni createPepperoni() 
return new SlicedPepperoni(); 

} 

public Clams createClam() { 
return new FreshClams(); 


new Onion(), new Mushroom(), new RedPepper() 

pov y/c vcb'AV-^ 3r\ 3v-v-ay o-f 

vc^ics. Wc tould make -tV^is move 
so^istida-ted, bui do^i really 
add -to -fad-tov-y 

pa 七七 SO y/C’ll kedp i 七 siw»\>lr 


}； 


|s/ey/ Yov-k is or\ doasi； it 
yts -fvcsV^ C^idago V^as 
io settle (or "(Voz^. 


TKc bes-t slided \>c\>\>CV-or»i. TWis 
is slaved between Vov-k 
and CWiday>. Make suv-c you 
use i-t or^ i\\t Yxt%i 4 你 

you yt "to 七 ^ 

C^ida^ 0 "f 3^"tov*Y youvscl-f 
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build a factory 


Sharpen your pencil 


Write the ChicagoPizzalngredientFactory. You can 
reference the classes below in your implementation: 


BlackOlives 


Spinach 


EggPlant 


SlicedPepperoni 


ThickCrustDough 


PlumTomatoSauce r 


FrozenClams 





Mozzarella 
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the factory pattern 


Reworking the pizzas... 

We’ve got our factories all fired up and ready to produce quality ingredients; now we 
just need to rework our Pizzas so they only use factory-produced ingredients. We’ll 
start with our abstract Pizza class: 


IZJZ^ Violds d Sti o( mycdicivts 
re used rn its p 吓 avafco". 


tVc'vc how r«adc -the f\rcpav-c method abs-tv-adt 
丁 his is y/Kcvc wc av-c goihj -to CoWtd -tKc 
•mycdicivb heeded -fov- -the piz^ ; y/hidh o*f 
douvsc will dome -fv-om -the mg\rcdiCK»-t -fad*tov-y. 

void bake() { 

System, out .println (''Bake for 25 minutes at 350"); 


void cut() { 

System, out .println (''Cutting the pizza into diagonal slices"); 


void box() { 

System, out .println (''Place pizza in official PizzaStore box"); 

} 

void setName(String name) { 
this . name = name; 


String getName() { 

return name; 


public String toString() { 

// code to print pizza here 

} 

} 


$ 


r 二工口 ： 


public abstract class Pizza { 
String name; 

Dough dough; / 

Sauce sauce; 匕 

Veggies veggies[]; 

Cheese cheese; 

Pepperoni pepperoni; 

Clams clam; 


Bath 
i\\ai a 、 


abstract void prepare(); 
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decoupling ingredients 


Reworking the pizzas, continued... 

Now that you’ve got an abstract Pizza to work from, it’s time to create 
the New York and Chicago style Pizzas — only this time around they will 
get their ingredients straight from the factory. The franchisees’ days of 
skimping on ingredients are over! 

When we wrote the Factory Method code, we had a NYCheesePizza and 
a ChicagoCheesePizza class. If you look at the two classes, the only thing 
that differs is the use of regional ingredients. The pizzas are made just 
the same (dough + sauce + cheese). The same goes for the other pizzas: 
Veggie, Clam, and so on. They all follow the same preparation steps; they 
just have different ingredients. 

So, what you’ll see is that we really don’t need two classes for each pizza; 
the ingredient factory is going to handle the regional differences for us. 
Here’s the Cheese Pizza: 


public class CheesePizza extends Pizza { 

PizzalngredientFactory ingredientFactory; 

public CheesePizza(PizzalngredientFactory ingredientFactory) 
this.ingredientFactory = ingredientFactory; 



▲ a 一 。” c need 
3ttov7 -to YV-ov'.de the 
- 咖 山 . So eatV, P'.^ 

—“a—d 


void prepare () { 

System, out .println (''Preparing '' + name); 
dough = ingredientFactory.createDough(); 
sauce = ingredientFactory. createSauce () ; 
cheese = ingredientFactory.createCheese(); 


a 6V>eese 0 以 ， ad ca 乩七 “e i 七 ^ 

.I asks to ?^odu6C .t- 
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(We Up Cl^se - 

The Pizza code uses the factory it has been composed with to produce the ingredients used in the 
pizza. The ingredients produced depend on which factory we’re using. The Pizza class doesn’t care; 
it knows how to make pizzas. Now, it’s decoupled from the differences in regional ingredients and 
can be easily reused when there are factories for the Rockies, the Pacific Northwest, and beyond. 


sauce = 

^ eVe ihe 
^Hab| e t 0 ^ ^ 

^ ^ -this pi 印. 


ingredientFactory.createSauce(); 


TV^is is ouv mycdicrrt -f 36 -tov-y. 
TV Piz^a docs^-t tare 
•fad-tov-y is used, 3 s lo^g 3 S i-t is 
a” myedie 灼七 -fadiov-y- 




s ㈣ :二 


Sdu 6 C- 


Let’s check out the ClamPizza as well: 


public class ClamPizza extends Pizza { 

PizzalngredientFactory ingredientFactory; 


public ClamPizza(PizzalngredientFactory ingredientFactory) 
this.ingredientFactory = ingredientFactory; 



{ 

Cla^P'iz^ also stashes ar\ 
•myedierrt *fadW/. 


void prepare () { 

System, out .println (''Preparing '' + name); 
dough = ingredientFactory.createDough(); 
sauce = ingredientFactory.createSauce(); 
cheese = ingredientFactory.createCheese(); 
clam = ingredientFactory.createClam(); 





To make a da 州 

^vc^av-c method dollct*U v •吵七 

mjvcdic^ts -fvom its lo^al 


it's a Hcvj York fadW /，， 
七 he d-larms y/ill be *fv*csV^j i-f 
CWiday, II be (roz£^. 
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use the right ingredient factory 


Revisiting our pizza stores 


We’re almost there; we just need to make a quick trip to our 
franchise stores to make sure they are using the correct 
Pizzas. We also need to give them a reference to their local 
ingredient factories: 


public class NYPizzaStore extends PizzaStore { 

protected Pizza createPizza(String item) { 
Pizza pizza = null; 

PizzalngredientFactory ingredientFactory 
new NYPizzalngredientFactory(); 


DO sed ^ 3 ^ 


if (item.equals (''cheese '’）） { 

pizza = new CheesePizza(ingredientFactory); 
pizza. setName (''New York Style Cheese Pizza"); 

} else if (item.equals ( 、 'veggie 〃）） { 

pizza = new VeggiePizza(ingredientFactory); 
pizza. setName (''New York Style Veggie Pizza"); 



Wc r\ov/ 

•fa^-tov-Y 七 should be used to 
^v-odutc its 



Look badk or\c page make suve 

You \AY\dtrsiar\d V^OV/ ttc 3r\d 

Y/ork 七亨 tW! 


} else if (item.equals ( 、 'clam 〃）） { 

pizza = new ClamPizza(ingredientFactory); 
pizza. setName (''New York Style Clam Pizza"); 

(t 

} else if (item.equals (''pepperoni^) ) { 

pizza = new PepperoniPizza(ingredientFactory); 
pizza. setName (''New York Style Pepperoni Pizza"); 




Fov eadh £ype of Piz^a, we 
ins-tan-tia-te a new Pizzj and jive 
i 七七 he fatio>ry \i hee ds h> 

_*ts ihjvcdicivts. 


return pizza; 

} 
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Compare this version of the createPizza() method 
to the one in the Factory Method implementation 
earlier in the chapter. 



the factory pattern 


What have we dowe? 

That was quite a series of 
code changes; what exactly 
did we do? 


We provided a means 
of creating a family of 
ingredients for pizzas by 
introducing a new type of 
factory called an Abstract 
Factory. 

An Abstract Factory gives 
us an interface for creating 
a family of products. By 
writing code that uses this 
interface, we decouple our 
code from the actual factory 
that creates the products. 
That allows us to implement 
a variety of factories that 
produce products meant for 
different contexts - such as 
different regions，different 
operating systems, or 
different look and feels. 

Because our code is 
decoupled from the actual 
products, we can substitute 
different factories to get 
different behaviors (like 
getting marinara instead of 
plum tomatoes). 


An Abstract Factory provides an interface for 
a family of products. What’s a family? In our 
case it’s all the things we need to make a pizza: 
dough, sauce, cheese, meats and veggies. 



\isicr^ u - 


\jectvilL^AIostlact SngledientlJ-actoly 



(or 

u 


flew Volk 




From the abstract factory, we 
derive one or more concrete 
factories that produce the same 
products, but with different 
implementations. 


We then write our code so that it uses the 
factory to create products. By passing in 
a variety of factories, we get a variety of 
implementations of those products. But 
our client code stays the same. 
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order some more pizza 


More pizza for Ethaw and Joel 


Ethan and Joel can't get enough Objectville Pizza! What they 
don't know is that now their orders are making use of the 
new ingredient factories. So now when they order... 


BeMnd /■ 
ihe Scenes 




the first part of the order process hasn't changed at 
all. Let's follow Ethan's order again: 


o 


First we need a NY PizzaStore: 



© 

❺ 


PizzaStore nyPizzaStore = new NYPizzaStore (); 


Cveaics ah ihs-ta h ^ c ^ 
时 i 如 SW 

Now that we have a store，we can take an order: 

nyPizzaStore . orderPizza (''cheese ”）； 


tV,e ^PiziaS-bve .msWe. 


The orderPizza() method first calls the ere- 
atePizza() method: 

Pizza pizza = createPizza (''cheese"); 
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the factory pattern 


From here things change, because we 
are using aw ingredient factory 


Beliind 

ihe Scenes^ 5 ^ 


When the createPizza() method is called, that’s 
when our ingredient factory gets involved: 


/ 


Pizza pizza = new CheesePizza(nylngredientFactory); 


C^rcaics a ihs-ta^c of 

Piiz4 that is Composed 
ihe A/ew y o yk — 
'«3^edieh£ ^aciovy. 




^edie' 


ierv^ 


Pizza 


A Next we need to prepare the pizza. Once the 
prepare() method is called, the factory is asked 
to prepare ingredients: 


void prepare() { 

dough = factory.createDough();〆" 
sauce = factory.createSauce(); 一 
cheese = factory.createCheese(); 


u ? \zxa ^ 
-fat-tov-v IS usc 山 







for tV^c in 

心七 ， s us< 

yi -tV^c KV mycd'»c^ts. 


Kc>w V<>v-k 
scd, ar^di so 


❻ 


Finally we have the prepared pizza in hand and the 
orderPizza() method bakes, cuts, and boxes the pizza. 
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abstract factory defined 


Abstract Factory Pattern defined 


We’re adding yet another factory pattern to our pattern family, one that lets us create families 
of products. Let’s check out the official definition for this pattern: 


The Abstract Factory Pattern provides an interface 
for creating families of related or dependent objects 
without specifying their concrete classes. 


We’ve certainly seen that Abstract Factory allows a client to use an abstract interface to 
create a set of related products without knowing (or caring) about the concrete products that 
are actually produced. In this way, the client is decoupled from any of the specifics of the 
concrete products. Let’s look at the class diagram to see how this all holds together: 


TV^C is y/vittc” aga'ms-t ttc 
abs-tv-ad-t ^ad-tovy and “c” to^ostd at 
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the factory pattern 


That’s a fairly complicated class 
diagram; let’s look at it all in terms of 
our PizzaStore: 



The tlicr»-ts Jc ttc 
Abs-tvad-t Fadiov-y avc 
七 he do^vctc ms-ta^cs o-f 
Piz^a abs*brad 七 dass. 
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interview with factory patterns 


O 


I noticed that each method in the 
Abstract Factory actually looks like a Factory 
Method (createDoughO, createSauceO, etc.). 
Each method is declared abstract and the 
subclasses override it to create some 
object. Isn't that Factory Method? 



Is that a Factory Method lurking inside the 
Abstract Factory? 

Good catch! Yes, often the methods of an Abstract Factory are 
implemented as factory methods. It makes sense, right? The job of an 
Abstract Factory is to define an interface for creating a set of products. 
Each method in that interface is responsible for creating a concrete 
product, and we implement a subclass of the Abstract Factory to 
supply those implementations. So, factory methods are a natural way to 
implement your product methods in your abstract factories. 



Pattern BxposefiJ 

This week’s interview: 

Factory Method and Abstract Factory, on each other 


Head First: Wow, an interview with two patterns at once! This is a first for us. 

Factory Method: Yeah, I’m not so sure I like being lumped in with Abstract Factory, 
you know. Just because we’re both factory patterns doesn’t mean we shouldn’t get our own 
interviews. 

Head First: Don’t be miffed, we wanted to interview you together so we could help clear up 
any confusion about who’s who for the readers. You do have similarities, and I’ve heard that 
people sometimes get you confused. 

Abstract Factory: It is true, there have been times I’ve been mistaken for Factory Method, 
and I know you’ve had similar issues, Factory Method. We’re both really good at decoupling 
applications from specific implementations; we just do it in different ways. So I can see why 
people might sometimes get us confused. 

Factory Method ： Well, it still ticks me off. After all, I use classes to create and you use 
objects; that’s totally different! 
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the factory pattern 


Head First: Can you explain more about that, Factory 
Method? 

Factory Method ： Sure. Both Abstract Factory and 
I create objects - that’s our jobs. But I do it through 
inheritance... 

Abstract Factory ： ...and I do it through object 
composition. 

Factory Method ： Right. So that means, to create 
objects using Factory Method, you need to extend a class 
and override a factory method. 

Head First: And that factory method does what? 

Factory Method ： It creates objects, of course! I mean, 
the whole point of the Factory Method Pattern is that 
you’re using a subclass to do your creation for you. In 
that way, clients only need to know the abstract type they 
are using, the subclass worries about the concrete type. 

So, in other words, I keep clients decoupled from the 
concrete types. 

Abstract Factory ： And I do too, only I do it in a 
different way. 

Head First: Go on, Abstract Factory... you said 
something about object composition? 

Abstract Factory ： I provide an abstract type for 
creating a family of products. Subclasses of this type 
define how those products are produced. To use the 
factory, you instantiate one and pass it into some code 
that is written against the abstract type. So, like Factory 
Method, my clients are decoupled from the actual 
concrete products they use. 

HeadFirst: Oh, I see, so another advantage is that you 
group together a set of related products. 

Abstract Factory: That’s right. 

Head First: What happens if you need to extend that 
set of related products, to say add another one? Doesn’t 
that require changing your interface? 

Abstract Factory ： That’s true; my interface has to 
change if new products are added, which I know people 
don’t like to do.... 

Factory Method: 〈 snicker 〉 

Abstract Factory ： What are you snickering at, 

Factory Method? 


Factory Method ： Oh, come on, that’s a big deal! 
Changing your interface means you have to go in and 
change the interface of every subclass! That sounds like a 
lot of work. 

Abstract Factory ： Yeah, but I need a big interface 
because I am used to create entire families of products. 
You’re only creating one product, so you don’t really need 
a big interface, you just need one method. 

Head First: Abstract Factory, I heard that you often use 
factory methods to implement your concrete factories? 

Abstract Factory ： Yes, I’ll admit it, my concrete 
factories often implement a factory method to create 
their products. In my case, they are used purely to create 
products... 

Factory Method ： ...while in my case I usually 
implement code in the abstract creator that makes use of 
the concrete types the subclasses create. 

Head First ： It sounds like you both are good at what 
you do. I’m sure people like having a choice; after all, 
factories are so useful, they’ll want to use them in all 
kinds of different situations. You both encapsulate 
object creation to keep applications loosely coupled 
and less dependent on implementations, which is really 
great, whether you’re using Factory Method or Abstract 
Factory. May I allow you each a parting word? 

Abstract Factory ： Thanks. Remember me, Abstract 
Factory, and use me whenever you have families of 
products you need to create and you want to make sure 
your clients create products that belong together. 

Factory Method ： And I’m Factory Method; use me to 
decouple your client code from the concrete classes you 
need to instantiate, or if you don’t know ahead of time 
all the concrete classes you are going to need. To use me, 
just subclass me and implement my factory method! 
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patterns compared 


Factory Method awd Abstract Factory compared 
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The KVPiziaS-tovc suklass o^ly 
ms-bntia-tcs KV s-tylc 0 ⑽ • 


TKis is -tV)C ^vodiud-t <>f -t^c 
PiziaS-tovc- Clieivts only 
vdy cm iWis abstract ty?c- 


The CWu^aoPiz^SW 
subclass ms-ta^-tia-tes or^ly 
CKidago style fizzes. 


NYStyleCheesePizza 

NYStylePepperoniPizza 

NYStyleClamPizza 


Subclasses avc ms-bniaied 
by b\c Fad-tov-y Methods. 




NYStyleVeggiePizza 1 

4 



C^idago - 


ChicagoStyleCheesePizza 1 

ChicagoStylePepperoniPizza 

ChicagoStyleClamPizza 1 
ChicagoStyleVeggiePizza 


TKc dvcaicPiziaO mciKod is ^avametev-iz^d by fiz^a 
bfyt) so y/c dan v-cium many -ty^cs products. 
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the factory pattern 


Provides a« abst^aft ^ 
■^ieyhu U freatm^ a 
family yvod^- 


«interface» 

PizzalngredientFactory 


createDoughf) 

createSaucef) 

createCheesef) 

createVeggiesf) 

createPepperonif) 

createClam() 








: cd "to tvcstc 


rtyo^a\ 崎 


oym 


Bath dontvrbc subclass 
dvcatcs a -family o-f yrod^U- 


Kcv/ Vo\rk 



•Jov ms-ta^c, -tKc subclass 
dcdidcs *tv>c ty^c of do—v. 


《 interface 》 

Dough 






NYPizzalngredientFactory 


ChicagoPizzalngredientFactory 

createDough() 


createDough() 

createSauce() 


createSauceO / 〆 

createCheese() 


createCheese() ^ 

createVeggies() 


createVeggies() 

createPepperoni() 


createPepperoni() J 

createClam() 


createClam() 





C^itajo 


McHodU to dv-caic ^vodud-ts 
•m an Abs-tv-ad-t Fad-tov-y avc 
of-ten i 叫 >1icd WiA a 
Fad-tovy Method - 


《 interface 》 

Clams 




ThinCrustDough | 

ThickCrustDough 


FreshClams 


Froze 门 Clams 

1 







«interface» 

Sauce 






MarinaraSauce 


PlumTomatoSauce 


Bach 哼以心七 

refrewb a 

^>y-odivA6*t *tV\3*t » s 
?\rodMcd h a 
fa^-torv 融 ^ 
•m Afe 士 ra 6 七 

fa^-bov'/- 


《 interface 》 

Cheese 






ReggianoCheese 


Mozzarella Cheese 


TKc ^vodudi subdlasscs dveate parallel sets o-f pvodudt •families, 
tteve y/c Kavc a Now V^k mgvcdic^-t -family ar\d a CK'^ago -family- 
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your design toolbox 


I 拿 Tools for your Pesigw toolbox 

I / In this chapter, we added two more tools to your 

toolbox: Factory Method and Abstract Factory. Both 
patterns encapsulate object creation and allow you to 
decouple your code from concrete types. 


A A • 声 , S 

oo ? 一 '— \ , \ 

⑽ —ak 咖 '。. \ » 

, 1 

„ to ^ attS， ^ \ 」 

ti; 一 '。… '“㈣ # 

\ VJt Kave a new pv'mtiple 七 ha 七 

cvv Jfov I guides us io iKmjs 

C\asse( absiva^-t >wKck\Cvcv possible. 

—We des'，. 


rc\ated c 

s^T 



c ,. OY . w 

m te^ ate j etl de I 

> \et 级广奶 Me tWd 

t “。， 

suV)t\asscs- 


BULLET POINTS 


■ All factories encapsulate object 
creation. 

■ Simple Factory, while not a bona 
fide design pattern, is a simple 
way to decouple your clients 
from concrete classes. 

■ Factory Method relies on 
inheritance: object creation is 
delegated to subclasses which 
implement the factory method to 
create objects. 

■ Abstract Factory relies on object 
composition: object creation 

is implemented in methods 
exposed in the factory interface. 

■ All factory patterns promote 
loose coupling by reducing the 
dependency of your application 
on concrete classes. 

■ The intent of Factory Method 
is to allow a class to defer 
instantiation to its subclasses. 

■ The intent of Abstract Factory 
is to create families of related 
objects without having to depend 
on their concrete classes. 

■ The Dependency Inversion 
Principle guides us to avoid 
dependencies on concrete types 
and to strive for abstractions. 

■ Factories are a powerful 
technique for coding to 
abstractions, not concrete 
classes 
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the factory pattern 



It’s been a long chapter. Grab a slice of Pizza and relax while doing 
this crossword; all of the solution words are from this chapter. 



Across 

I. In Factory Method, each franchise is a 

4. In Factory Method, who decides which class 
to instantiate? 

6. Role of PizzaStore in Factory Method Pattern 

7. All New York Style Pizzas use this kind of 
cheese 

8. In Abstract Factory, each ingredient factory is 

a_ 

9. When you use new, you are programming to 

an_ 

II. createPizza() is a_(two 

words) 

12. Joel likes this kind of pizza 

13. In Factory Method, the PizzaStore and the 
concrete Pizzas all depend on this abstraction 

14. When a class instantiates an object from a 

concrete class, it’s_on that object 

15. All factory patterns allow us to_ 

object creation 


Down 

2. We used_ in Simple Factory 

and Abstract Factory and inheritance in Factory 
Method 

3. Abstract Factory creates a_of 

products 

5. Not a REAL factory pattern, but handy 
nonetheless 

10. Ethan likes this kind of pizza 


you are here ► 
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exercise solutions 



Exercise solutions 


Sharpen your pencil 


We’ve knocked out the NYPizzaStore; just two more to go and we’ll be ready to franchise! 
Write the Chicago and California PizzaStore implementations here: 

^ WWUmds ，细 


public class ChicagoPizzaStore extends PizzaStore { 
protected Pizza createPizza(String item) { 
if (item.equals (''cheese ”）） { 

return new ChicagoStyleCheesePizza(); ^ 

} else if (item.equals (''veggie ”）） { 

return new ChicagoStyleVeggiePizza(); k 
} else if (item.equals ( 、 'clam 〃）） { 

return new ChicagoStyleClamPizza(); 

} else if (item.equals ( 、 'pepperoni 〃）） { 

return new ChicagoStylePepperoniPizza(); 

} else return null; 




卜枷 CWta 沪？ 巧 3 

.j wsUa ' 。 

.„ake 抓⑽ tveate 

CW ， 妙 … s … 


public class CaliforniaPizzaStore extends PizzaStore { 
protected Pizza createPizza(String item) { 
if (item.equals ( 、 'cheese 〃）） { 

return new CaliforniaStyleCheesePizza(); 3^ 


^ -t^e CaV^ovn.a 
6v*ca*tc 


else if (item, equals (''veggie") ) { fzxa s*tovc> 1 

return new CaliforniaStyleVeggiePizza(); ^ 0 CaliWa 妙 V ， 谈 
else if (item.equals ( 、 'clam 〃）） { 

return new CaliforniaStyleClamPizza(); 
else if (item, equals (''pepperoni^) ) { 

return new CaliforniaStylePepperoniPizza () 
else return null; 


u 
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the factory pattern 


Design Puzzle Solution 

We need another kind of pizza for those crazy Californians (crazy in a GOOD way of 
course). Draw another parallel set of classes that you’d need to add a new California 
region to our PizzaStore. 



Okay, now write the five silliest things you can think of to put on a pizza. Then, you’ll 
be ready to go into business making pizza in California! 

猗 eg 左二二 f Poia-fcoes y/i-fcK Roas-fced _ 

BB 夕 Sgude_ 

A^rii^Koke Heavis_ 

_ 

Peanuts 
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exercise solutions 


A very dependent FizzaStorc 


cf^|harpen your pencil 


Let’s pretend you’ve never heard of an OO factory. Here’s a version of the PizzaStore 
that doesn’t use a factory; make a count of the number of concrete pizza objects this 
class is dependent on. If you added California style pizzas to this PizzaStore, how many 
objects would it be dependent on then? 


public class DependentPizzaStore { 


public Pizza createPizza(String style, 
Pizza pizza = null; 
if (style• equals ( 、 'NY〃））{ 

if (type.equals ( 、 'cheese 〃）） { 


String type) { 


pizza 
else if 
pizza 
else if 
pizza 
else if 
pizza 


=new NYStyleCheesePizza(); 
(type.equals (''veggie") ) { 

=new NYStyleVeggiePizza(); 
(type• equals (''clam") ) { 

=new NYStyleClamPizza(); 

(type.equals (''pepperoni") ) { 

=new NYStylePepperoniPizza (). 


Handles all NV 
s-tylc 


else if (style ■ equals ( 、 'Chicago〃> ) 
if (type.equals ( 、 'cheese 〃）） { 


pizza 
else if 
pizza 
else if 
pizza 
else if 
pizza 


=new ChicagoStyleCheesePizza() 
(type.equals (''veggie") ) { 

=new ChicagoStyleVeggiePizza() 
(type• equals (''clam") ) { 

=new ChicagoStyleClamPizza(); 
(type.equals (''pepperoni") ) { 

=new ChicagoStylePepperoniPizza() 




Hailes all 
CW ， 6ay> style 

▽iz^as 


else { 

System, out .println (''Error : 
return null; 


invalid type of pizza"); 


pizza.prepare(); 
pizza.bake(); 
pizza.cut(); 
pizza.box(); 
return pizza; 


V^ou t^Y\ y/vi-tc 
your ansv/evs Kcrc ： 


e 




IZ 
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the factory pattern 


Sharpen your pencil - 

Go ahead and write the ChicagoPizzalngredientFactory; you can reference the 
classes below in your implementation: 


public class ChicagoPizzalngredientFactory 
implements PizzalngredientFactory 

{ 

public Dough createDough () { 

return new ThickCrustDough(); 


public Sauce createSauce () { 

return new PlumTomatoSauce(); 


public Cheese createCheese () { 

return new MozzarellaCheese (); 


public Veggies[] createVeggies() { 

Veggies veggies[] = { new BlackOlives(), 

new Spinach(), 
new Eggplant() }; 

return veggies; 

} 

public Pepperoni createPepperoni() { 

return new SlicedPepperoni(); 


public Clams createClam() { 
return new FrozenClams(); 


BlackOlives 


Spinach 


EggPlant 


ThickCrustDough 


SlicedPepperoni 


PlumTomatoSauce r 


FrozenClams 





MozzarellaCheese 
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crossword puzzle solution 



Puzzle Solution 
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5 th 


e 


fwtem 


♦ One of a Kind Objects ♦ 



I tell ya she's ONE OF A 
KIND. Look at the lines, 
the curves, the body, 
the headlights! 


Our next stop is the Singleton Pattern, our ticket to creating one- 
of-a-kind objects for which there is only one instance. You might be 

happy to know that of all patterns, the Singleton is the simplest in terms of its class diagram; 
in fact, the diagram holds just a single class! But don’t get too comfortable; despite its 
simplicity from a class design perspective, we are going to encounter quite a few bumps and 
potholes in its implementation. So buckle up. 


this is a new chapter 
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one and only one 



Developer: What use is that? 

Guru: There are many objects we only need one of: thread pools, caches, dialog boxes, objects that handle 
preferences and registry settings, objects used for logging, and objects that act as device drivers to devices 
like printers and graphics cards. In fact, for many of these types of objects, if we were to instantiate 
more than one wed run into all sorts of problems like incorrect program behavior, overuse of resources, or 
inconsistent results. 

Developer: Okay, so maybe there are classes that should only be instantiated once, but do I need a whole 
chapter for this? Can't I just do this by convention or by global variables? You know, like in Java, I could do it 
with a static variable. 

Guru: In many ways, the Singleton Pattern is a convention for ensuring one and only one object is instantiated 
for a given class. If you've got a better one, the world would like to hear about it; but remember, like all 
patterns, the Singleton Pattern is a time-tested method for ensuring only one object gets created. The 
Singleton Pattern also gives us a global point of access, just like a global variable, but without the downsides. 

Developer: What downsides? 

Guru: Well, here's one example ： if you assign an object to a global variable, then that object might be created 
when your application begins. Right? What if this object is resource intensive and your application never ends 
up using it? As you will see, with the Singleton Pattern, we can create our objects only when they are needed. 

Developer: This still doesn't seem like it should be so difficult. 

Guru: If youve got a good handle on static class variables and methods as well as access modifiers, it’s not. 
But, in either case, it is interesting to see how a Singleton works, and, as simple as it sounds, Singleton code is 
hard to get right. Just ask yourself ： how do I prevent more than one object from being instantiated? It’s not 
so obvious, is it? 
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The Little Singleton 

A small Socratic exercise in the style of The Little Lisper 


the singleton pattern 


How would you create a single object? 


new MyObject(); 


And, what if another object wanted to create a Yes, of course. 

MyObject? Could it call new on MyObject again? 


So as long as we have a class, can we always Yes. Well, only if it’s a public class, 

instantiate it one or more times? 


And if not? Well, if it’s not a public class, only classes in the same 

package can instantiate it. But they can still instantiate 
it more than once. 


Hmm, interesting. 

Did you know you could do this? 


No, I’d never thought of it, but I guess it makes 
sense because it is a legal definition. 


public MyClass { 

private MyClass() {} 


What does it mean? 


I suppose it is a class that can’t be instantiated 
because it has a private constructor. 


Well, is there ANY object that could use 
the private constructor? 


Hmm, I think the code in MyClass is the only 
code that could call it. But that doesn’t make 
much sense. 
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creating a singleton 


Why not ? Because I’d have to have an instance of the 

class to call it, but I can’t have an instance 
because no other class can instantiate it. It’s 
a chicken and egg problem: I can use the 
constructor from an object of type MyClass, 
but I can never instantiate that object because 
no other object can use “new MyClassQ”. 


MyClass is a class with a static method. We can 
call the static method like this: 

MyClass.getlnstance 0 / 

public MyClass { 

public static MyClass getlnstance() { 


Okay. It was just a thought. 
What does this mean? 


Why did you use MyClass, instead of 
some object name? 


Well, getlnstanceQ is a static method; in other 
words, it is a CLASS method. You need to use 
the class name to reference a static method. 


Very interesting. What if we put things together. Wow, you sure can. 

Now can I instantiate a MyClass? 


public MyClass { 

private MyClass() {} 

public static MyClass getlnstance() { 

return new MyClass(); 

} 

} 


So, now can you think of a second way to instantiate MyClass . getlnstance (); 

an object? 


Can you finish the code so that only ONE instance 
of MyClass is ever created? 
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Yes, I think so... 

(You’ll find the code on the next page.) 











the singleton pattern 


dissecting the classic Singleton 
Pattern implementatioH 

MvCIass 

〔 I 。 S—cW 

public class Singleton { < 

private static Singleton uniquelnstance 

// other useful instance variables here 

4 ： - - 〜 CW tonsirutioT is 

private Singleton () { } detlaved private 









If you’re just 
flipping through 
the book, don’t 
blindly type in this 
code, you’ll see a 
it has a few issues 
later in the chapter. 


uniquelnstance; 


// op ler useful methods here 




orvl^ 63 ^ 

tW»s tlass. 


publi(^si^feTL： biiiyleLuii ytiLTi^sJ^aTice () 

(uniquelnstance == null) { 
uniquelnstance = new Singleton A) ^ 

} ) The yilr\siaueO 

•^ctKod jives us a way 
"to ms*ta>rtia*tc the dldss 
ahd also io vc-tuv^ ah 
ihS-tahde of i*t. 

沉 to ^- Sihglet,,, is 
3 … al class ； i£ has 

。■^ ev we-Pul i hs ^ e 

vaviables a»d «, e -thods. 


C<dd^ Tjp 


e 


ur»i^uc|nS't 3 r\d.C Kolds ouv OHB- 

ms-tandc ； vewembev, it is a 
statid. vaviablc. 


if (uniquelnstance 
uniquelnstance 

} 

return uniquelnstance; 


«v.lUV>e« >we 

… and, i*f i 七 docsn’ 七 c^is-t, wc 
ms-ta^tia-tc S'mjlcton -tKv-oujK iis 
^>viva*tc dons*brud 七 ov and assign 
i 七七。 uni<\uc|hS't3y\dc. No"tc 七 
i-f y/C nevcv need ms-ta^dc, it 
wev gets dv-catcd; *tVis is laz.y 
ms-ta^tiatioy\. 


null) { 
new MyClass() 



|-f uy\i^uc|ns-tand.C y/asn’ 七 null, 

七 hen ii >/as ^vcviously dveated- 
\Ht jus-t -fall -tKvoujK -to tlic 
By iht -time >/C Kit t^is todt, y/C s*ta 七⑽ Ctvb 

Kave an instate and y/c \rctuv-n it- 


you are here ► 173 



interview with singleton 


Head First: Today we are pleased to bring you an interview with a Singleton object. Why don’t 
you begin by telling us a bit about yourself. 

Singleton ： Well, I’m totally unique; there is just one of me! 

HeadFirst: One? 

Singleton ： Yes, one. I’m based on the Singleton Pattern, which assures that at any one time 
there is only one instance of me. 

Head First: Isn’t that sort of a waste? Someone took the time to develop a full-blown class and 
now all we can get is one object out of it? 

Singleton ： Not at all! There is power in ONE. Let’s say you have an object that contains 
registry settings. You don’t want multiple copies of that object and its values running around 
— that would lead to chaos. By using an object like me you can assure that every object in your 
application is making use of the same global resource. 

HeadFirst ： Tell us more... 

Singleton: Oh, I’m good for all kinds of things. Being single sometimes has its advantages you 
know. I’m often used to manage pools of resources, like connection or thread pools. 

HeadFirst ： Still, only one of your kind? That sounds lonely. 

Singleton ： Because there’s only one of me, I do keep busy, but it would be nice if more 
developers knew me — many developers run into bugs because they have multiple copies of 
objects floating around they’re not even aware of. 

HeadFirst: So, if we may ask, how do you know there is only one of you? Can’t anyone with a 
new operator create a “new you ”？ 

Singleton ： Nope! I’m truly unique. 

HeadFirst ： Well, do developers swear an oath not to instantiate you more than once? 

Singleton ： Of course not. The truth be told... well, this is getting kind of personal but... I 
have no public constructor. 

HeadFirst ： NO PUBLIC CONSTRUCTOR! Oh, sorry, no public constructor? 

Singleton ： That’s right. My constructor is declared private. 

HeadFirst ： How does that work? How do you EVER get instantiated? 

Singleton ： You see, to get a hold of a Singleton object, you don’t instantiate one, you just ask 
for an instance. So my class has a static method called getlnstanceQ. Call that, and I’ll show up 
at once, ready to work. In fact, I may already be helping other objects when you request me. 

HeadFirst Well, Mr. Singleton, there seems to be a lot under your covers to make all this work. 
Thanks for revealing yourself and we hope to speak with you again soon! 



Fattens Bxposedi 

This week’s interview: 
Confessions of a Singleton 
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the singleton pattern 


The Chocolate Factory 

Everyone knows that all modern chocolate factories have computer controlled 
chocolate boilers. The job of the boiler is to take in chocolate and milk, bring them 
to a boil, and then pass them on to the next phase of making chocolate bars. 


Here’s the controller class for Choc-O-Holic, Inc.’s industrial strength Chocolate 
Boiler. Check out the code; you’ll notice they’ve tried to be very careful to ensure 
that bad things don’t happen, like draining 500 gallons of unboiled mixture, or 
filling the boiler when it’s already full, or boiling an empty boiler! 


public class ChocolateBoiler { 
private boolean empty; 
private boolean boiled; 


public ChocolateBoiler() 
empty = true; 
boiled = false; 



This dode is o^ly started 
v/Ken boilcv is 



} 

public void fill() { 
if (isEmpty()) { 
empty = false; 
boiled = false; 





// fill the boiler with a milk/chocolate mixture 


} 


public void drain() { 

if (!isEmpty() && isBoiled()) { 
// drain the boiled milk and 
empty = true; 



chocolate 


To dv-a'm tKc boiler, i 七 wus 七 be full 
(non cm\>-ky) and also boiled- 0r\U i-t is 
dv-amed set badk to tv-uc. 


} 


public 

if 


} 


void boil() { 


(!isEmpty() && !isBoiled()) { 

// bring the contents to a boil^ 
boiled = true; 


To boil iKc 你 ixtuve, the boilev 

has to be “11 ahd hot already 
boiled- Ot\tt s boiled wc set 
the boiled -flag -to -tvuc. 


public boolean isEmpty() { 

return empty; 

} 


public boolean isBoiled() { 

return boiled; 

} 
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chocolate boiler singleton 





Choc-O-Holic has done a decent job of ensuring bad things don’t happen, don’t ya think? Then 
again, you probably suspect that if two ChocolateBoiler instances get loose, some very bad 
things can happen. 

How might things go wrong if more than one instance of ChocolateBoiler is created in an 
application? 


Can you help Choc-O-Holic improve their ChocolateBoiler class 
by turning it into a singleton? 


public class ChocolateBoiler { 
private boolean empty; 
private boolean boiled; 


terpen your pencil 


ChocolateBoiler() { 

empty = true; 
boiled = false; 


public void fill () { 
if (isEmpty()) { 
empty = false; 
boiled = false; 

// fill the boiler with a milk/chocolate mixture 


// rest of ChocolateBoiler code... 
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Singleton Pattern defined 

Now that you’ve got the classic implementation of Singleton 
in your head, it’s time to sit back, enjoy a bar of chocolate, 
and check out the finer points of the Singleton Pattern. 

Let’s start with the concise definition of the pattern: 


The Singleton Pattern ensures a class has only one 
instance, and provides a global point of access to it. 


No big surprises there. But, let’s break it down a bit more: 

■ What’s really going on here? We’re taking a class and letting it manage a 
single instance of itself. We’re also preventing any other class from creating a 
new instance on its own. To get an instance, you’ve got to go through the class 
itself. 

■ We’re also providing a global access point to the instance: whenever you 
need an instance, just query the class and it will hand you back the single 
instance. As you’ve seen, we can implement this so that the Singleton is created 
in a lazy manner, which is especially important for resource intensive objects. 


Okay ， let’s check out the class diagram: 




,, A ； s 

Jfvo 州 7 a V)\c, ^ 

T 二 


Singleton 


static uniquelnstance 
II Other useful Singleton data.. 



static getlnstancef) 

II Other useful Singleton methods... 


T^c ur\i^ucks-b3^dc 
dlass variable holds ouv 
ov\t a^d o^ly ms-ta^dc 
of 


itisa^al ? ur ? os e 6lass^.ts 

set o-f daia a«d me 七 Ws. 
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threads are a problem 

Hoostwirwe have a problem... 

It looks like the Chocolate Boiler has let us down; despite 
the fact we improved the code using Classic Singleton, 
somehow the ChocolateBoiler’s fill() method was able 
to start filling the boiler even though a batch of milk and 
chocolate was already boiling! That’s 500 gallons of spilled 
milk (and chocolate)! What happened!? 


We don’t know what happened! The 
new Singleton code was running fine. The only 
thing we can think of is that we just added some 
optimizations to the Chocolate Boiler Controller 
that makes use of multiple threads. 




Could the addition of threads have caused 
this? Isn’t it the case that once we’ve set 
the uniquelnstance variable to the sole 
instance of ChocolateBoiler, all calls to 
getlnstance() should return the same 
instance? Right? 
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BE JVM 


Me have two iireads, eacK executing iliis code. Your job is to play iie JVM 
ffi and determine wKefier iliere is a case in wliicK two breads ^et aKold 
& different boiler objects. Hint- 
U you really just need to look at Ae 
sentence of operations 
in^xe getlnstance() 

^ ； 'J9r^^V mefliod and Ae value of 

unicpielnstance to see 

)Kow Aey might overlap. 

Use Ae code Magnets to Kelp 

you study Kowiie code mi^rt interleave to create two boiler objects. 


ChocolateBoiler boiler = 

ChocolateBoiler.getlnstance() 

fillO ； 
boil (); 
drain (); 


public static ChocolateBoiler 
getlnstance () { 


Make sure you check your answer on 
page 188 before turning the page! 


Value of 
unicpielnstance 
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multithreading and singleton 


Pealiwg with multithreading 

Our multithreading woes are almost trivially fixed by making 
getlnstance() a synchronized method: 


public class Singleton { 

private static Singleton 

// other useful instance 

private Singleton () {} 


uniqueInstance; 





public static synchronized Singleton getlnstance() { 

if (uniqueInstance == null) { 

uniquelnstance = new Singleton(); 


return uniquelnstance; 


// other useful methods here 


I agree this 
fixes the problem. 
But synchronization 
is expensive; is this an 
issue? 


Good point, and it’s actually a little worse than you make out: the only 
time synchronization is relevant is the first time through this method. In 
other words, once we’ve set the uniquelnstance variable to an instance 
of Singleton, we have no further need to synchronize this method. After 
the first time through, synchronization is totally unneeded overhead! 
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the singleton pattern 


Can we improve multithreading? 


For most Java applications, we obviously need to ensure that the Singleton works in the presence 
of multiple threads. But, it looks fairly expensive to synchronize the getlnstance 。 method, so what 
do we do? 

Well, we have a few options... 

1. Po nothing if the performance of getlnstanceO isn't critical to 
your application 

That’s right; if calling the getlnstance。method isn’t causing substantial overhead for your 
application, forget about it. Synchronizing getlnstance() is straightforward and effective. Just keep 
in mind that synchronizing a method can decrease performance by a factor of 100, so if a high 
traffic part of your code begins using getlnstanceQ, you may have to reconsider. 


2. Move to aw eagerly created instance rather thaw a lazily 
created one 

If your application always creates and uses an instance of the Singleton or the overhead of 
creation and runtime aspects of the Singleton are not onerous, you may want to create your 
Singleton eagerly, like this: 


public class Singleton { 

private static Singleton uniquelnstance 

private Singleton() {} 

public static Singleton getlnstance() { 

return uniquelnstance; 

} < - 




new Singleton(); 


、 
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Using this approach, we rely on the JVM to create the unique instance of the Singleton when 
the class is loaded. The JVM guarantees that the instance will be created before any thread 
accesses the static uniquelnstance variable. 
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$. Use "double - checked locking" to reduce the use of 
synchronization iw getinstahceO 

With double-checked locking, we first check to see if an instance is created, and if not, THEN we 
synchronize. This way, we only synchronize the first time through, just what we want. 

Let’s check out the code: 


public class Singleton 
private (^olatil^s 


{ 

tatic Singleton uniquelnstance; 


private Singleton() {} 


public static Singleton getlnstance() { 
if (uniqueInstance == null) { 

synchronized (Singleton.class) { 
if (uniqueInstance == null) { 

uniqueInstance = new Singleton() 

} 

} 

} 〜 

return uniquelnstance; 一 0 „te ih blodk, dhedk 33am a„d 

} i-f s-ti|| null, iyeaie ins-ta^de. 
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If performance is an issue in your use of the getlnstance() method then this method of 
implementing the Singleton can drastically reduce the overhead. 



Double-checked locking doesn’t 

work in Java 1-4 or earlier! 


t ha t allow improper synchronization for doub e-checkea 
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Meawwhik back at the Chocolate Factory... 

While we’ve been off diagnosing the multithreading problems, the chocolate boiler 
has been cleaned up and is ready to go. But first，we have to fix the multithreading 
problems. We have a few solutions at hand, each with different tradeoffs, so which 
solution are we going to employ? 



Sharpen your pencil 


For each solution, describe its applicability to the problem of fixing the Chocolate 
Boiler code: 


Synchronize the getlnstance() method: 


Use eager instantiation: 


Double-checked locking: 


Congratulations! 


At this point, the Chocolate Factory is a happy customer and Choc-O-Holic was glad to have some 
expertise applied to their boiler code. No matter which multithreading solution you applied, the boiler 
should be in good shape with no more mishaps. Congratulations. You’ve not only managed to escape 
5001bs of hot chocolate in this chapter, but you’ve been through all the potential problems of the Singleton. 
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q&a about singleton 


Duifil^t^uestipns 


For such a simple pattern 
consisting of only one class, 
Singletons sure seem to have some 
problems. 

Well, we warned you up 
front! But don’t let the problems 
discourage you; while implementing 
Singletons correctly can be tricky, after 
reading this chapter you are now 
well informed on the techniques for 
creating Singletons and should use 
them wherever you need to control 
the number of instances you are 
creating. 


Can't ■ just create a class in 
which all methods and variables are 
defined as static? Wouldn’t that be 
the same as a Singleton? 

Yes, if your class is self- 
contained and doesn’t depend on 
complex initialization. However, 
because of the way static 
initializations are handled in Java, 
this can get very messy, especially if 
multiple classes are involved. Often 
this scenario can result in subtle, 
hard to find bugs involving order 
of initialization. Unless there is a 
compelling need to implement your 
"singleton” this way, it is far better to 
stay in the object world. 


What about class loaders? 

I heard there is a chance that two 
class loaders could each end up with 
their own instance of Singleton. 

為 ^: Yes, that is true as each class 
loader defines a namespace. If you 
have two or more classloaders, you 
can load the same class multiple times 
(once in each classloader). Now, if that 
class happens to be a Singleton, then 
since we have more than one version 
of the class, we also have more than 
one instance of the Singleton. So, if 
you are using multiple classloaders 
and Singletons, be careful. One way 
around this problem is to specify the 
classloader yourself. 



Rumors of Singletons being eaten by the garbage 
collectors are greatly exaggerated 

Prior to Java 1.2, a bug in the garbage collector allowed Singletons 
to be prematurely collected if there was no global reference to them. In other 
words, you could create a Singleton and if the only reference to the Singleton 
was in the Singleton itself, it would be collected and destroyed by the garbage 
collector. This leads to confusing bugs because after the Singleton is 
“collected,” the next call to getlnstance() produced a shiny new Singleton. In 
many applications, this can cause confusing behavior as state is mysteriously 
reset to initial values or things like network connections are reset. 

Since Java 1.2 this bug has been fixed and a global reference is no longer 
required. If you are, for some reason, still using a pre-Java 1.2 JVM, then be 
aware of this issue, otherwise, you can sleep well knowing your Singletons 
won’t be prematurely collected. 
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I’ve always been taught that 
a class should do one thing and one 
thing only. For a class to do two 
things is considered bad 00 design. 
Isn’t a Singleton violating this? 

You would be referring to 
the "One Class, One Responsibility" 
principle, and yes, you are correct, 
the Singleton is not only responsible 
for managing its one instance (and 
providing global access), it is also re¬ 
sponsible for whatever its main role is 
in your application. So, certainly it can 
be argued it is taking on two respon¬ 
sibilities. Nevertheless, it isn’t hard 


I wanted to subclass my 
Singleton code, but I ran into 
problems. Is it okay to subclass a 
Singleton? 

One problem with subclassing 
Singleton is that the constructor is 
private. You can’t extend a class with 
a private constructor. So, the first 
thing you’ll have to do is change 
your constructor so that it’s public 
or protected. But then, it’s not really 
a Singleton anymore, because other 
classes can instantiate it. 

If you do change your constructor, 
there’s another issue. The 


to see that there is utility in a class 
managing its own instance; it certainly 
makes the overall design simpler. In 
addition, many developers are familiar 
with the Singleton pattern as it is in 
wide use. That said, some developers 
do feel the need to abstract out the 
Singleton functionality. 


implementation of Singleton is based 
on a static variable, so if you do a 
straightforward subclass, all of your 
derived classes will share the same 
instance variable. This is probably 
not what you had in mind. So, for 
subclassing to work, implementing 
registry of sorts is required in the base 
class. 


I still don’t totally understand 
why global variables are worse than 
a Singleton. 

In Java,global variables are 
basically static references to objects. 
There are a couple of disadvantages 
to using global variables in this 
manner. We’ve already mentioned 
one: the issue of lazy versus eager 
instantiation. But we need to keep 
in mind the intent of the pattern: to 
ensure only one instance of a class 
exists and to provide global access. A 
global variable can provide the latter, 
but not the former. Global variables 
also tend to encourage developers 
to pollute the namespace with lots 
of global references to small objects. 
Singletons don’t encourage this in 
the same way, but can be abused 
nonetheless. 


Before implementing such a scheme, 
you should ask yourself what you 
are really gaining from subclassing 
a Singleton. Like most patterns, the 
Singleton is not necessarily meant 
to be a solution that can fit into a 
library. In addition, the Singleton code 
is trivial to add to any existing class. 
Last, if you are using a large number 
of Singletons in your application, 
you should take a hard look at your 
design. Singletons are meant to be 
used sparingly. 
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Tools for your design Toolbox 

You’ve now added another pattern to your 
toolbox. Singleton gives you another method 
off creating objects - in this case, unique 


objectr 
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BULLET POINTS 


■ The Singleton Pattern ensures 
you have at most one instance 
of a class in your application. 

■ The Singleton Pattern also 
provides a global access point 
to that instance. 

■ Java’s implementation of the 
Singleton Pattern makes use 
of a private constructor, a static 
method combined with a static 
variable. 

■ Examine your performance 
and resource constraints and 
carefully choose an appropriate 
Singleton implementation for 
multithreaded applications 
(and we should consider all 
applications multithreaded!). 

■ Beware of the double-checked 
locking implementation; it is not 
thread-safe in versions before 
Java 2, version 5. 

■ Be careful if you are using 
multiple class loaders; this 
could defeat the Singleton 
implementation and result in 
multiple instances. 

■ If you are using a JVM earlier 
than 1.2, you’ll need to create a 
registry of Singletons to defeat 
the garbage collector. 
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Sit back, open that case of chocolate that you were sent for solving 
the multithreading problem, and have some downtime working on 
this little crossword puzzle ； all of the solution words are from this 
chapter. 



Across 

1. It was "one of a kind" 

2. Added to chocolate in the boiler 

8. An incorrect implementation caused this to 
overflow 

10. Singleton provides a single instance and 
(three words) 

12. Flawed multithreading approach if not using 
Java 1.5 

13. Chocolate capital of the US 

14. One advantage over global variables: 
_creation 

15. Company that produces boilers 

16. To totally defeat the new constructor, we 

have to declare the constructor_ 


Down 

1. Multiple_can cause problems 

3. A Singleton is a class that manages an 

instance of_ 

4. If you don't need to worry about lazy 
instantiation, you can create your instance 


5. Prior to 1.2, this can eat your Singletons (two 
words) 

6. The Singleton was embarassed it had no 

public_ 

7. The classic implementation doesn't handle 
this 

9. Singleton ensures only one of these exist 
11. The Singleton Pattern has one 
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Exercise 

Solutions 






Hiead 

One 


TKead 

Two 


public static ChocolateBoiler 
getlnstance() { 


Value of 
uniquelnstance 


public static ChocolateBoiler 
getlnstance() { 


if (uniqueInstance == null) 


I if (uniqueInstance == null) 


uniquelnstance = 

new ChocolateBoiler(); 


return uniquelnstance; 


uniquelnstance = 

new ChocolateBoiler(); 


return uniquelnstance; 


null 

<objectl> 

<objectl> 

<object2 ： 

<object2> 


_UV^ oK tw»s dotsy^i 
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•hs-tahdes^/ 
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the singleton pattern 



For each solution, describe its applicability to the problem of fixing the Chocolate 
Boiler code: 

Synchronize the getlnstance() method: 

A sivaioiKi-fovv/avd 七 e 乙 imi 气 ue ihai is ojuava^ 七 eed io wovk- Wc doy/ 七 seerw jo Kave ar>y 

pc'r-fovmandc dor\tcv-ns y/i-tK -the dhodolaic boilev, so "this would be 3 ^ood C.\\o\C.t- 


Use eager instantiation: 

iVc avc always -to ms-tan-tiaic -tKc tKodolaic boilev m ouv dode ； so s-ta-tidally mializj^ -tKc 

'ms-tar\tc v/ould £3use r\o This solu-tio^ would y/ovk as y/ell ds -tKc syr\dKvor»i«d method, 

aliKou^K pcvKaps be less obvious -to a dcvclopcv "farwilav wiiK -tKe sia^dard paiicv-n. 

Double checked locking: 
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Exercise solutions 
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6 the Command ?qttern 



♦ Encapsulating Invocation 





In this chapter, we take encapsulation to a whole new level: 
we’re going to encapsulate method invocation. That's right, by 


encapsulating method invocation, we can crystallize pieces of computation so that the 
object invoking the computation doesn’t need to worry about how to do things, it just uses 


our crystallized method to get it done. We can also do some wickedly smart things with 
these encapsulated method invocations, like save them away for logging or reuse them to 


implement undo in our code. 


this is a new chapter 
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home automation or bust 




Home Xut 0 mati 0 n 0 f Bust, Inc. 
1221 Industfial Avenue, Suite 2ooo 
Future Clta. IL 62914 


Greetings! 

I recently received a demo and briefing from Johnny 
Hurricane, CEO of Weather-O-Rama, on their new 
expandable weather station. I have to say, I was so + 
impressed with the software architecture that I’d like to 
ask you to design the API for our new Home Automation 
Remote Control. In return for your services we，d be Happy 
to handsomely reward you with stock options in Home 
Automation or Bust, Inc. 

I，m enclosing a prototype of our ground-breaJsing remote 
control for your perusal. The remote control features seven 
programmable slots (each can be assigned to a different 
household device) along with corresponding on/off buttons 
for each. The remote also has a global undo button. 

I，m also enclosing a set of Java classes on CD-R that were 
created by various vendors to control home automation 
devices such as lights, fans, hot tubs, audio equipment, and 
other simil3*r controllable appliances. 

We，d like you to create an API for programming the remote 
so that each slot can be assigned to control a device or set of 
devices. Note that it is important that we be able to control 
the current devices on the disc, and also any future devices 
that the vendors may supply. 

Given the work you did on the Weather-O-Rama weather 
station, we know you’ll do a great job on our remote control. 

We look forward to seeing your design. 

Sincerely, 

Bill “X-10” Thompson, CEO 
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Free hardware! Let§ check out the Remote Control. 
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Taking a look at the vendor classes 



It looks like we have quite a set of classes here, and not a lot of 
industry effort to come up with a set of common interfaces. Not 
only that, it sounds like we can expect more of these classes in the 
future. Designing a remote control API is going to be interesting. 
Let’s get on to the design. 
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Cubicle Cowversatiow 

Your teammates are already discussing how to design the remote control API... 





Well, we've got another design to do. 

My first observation is that we've got a 
simple remote with on and off buttons but 
set of vendor classes that are quite 
diverse. 



Mary: Yes ， I thought we’d see a bunch of classes with on() 
and offQ methods, but here we’ve got methods like dimQ, 
setTemperatureO, setVolumeO, setDirectionO- 

Sue: Not only that, it sounds like we can expect more vendor 
classes in the future with just as diverse methods. 

Mary: I think it’s important we view this as a separation of 
concerns: the remote should know how to interpret button presses 
and make requests, but it shouldn’t know a lot about home 
automation or how to turn on a hot tub. 


Sue: Sounds like good design. But if the remote is dumb and 
just knows how to make generic requests, how do we design the 
remote so that it can invoke an action that, say，turns on a light or 
opens a garage door? 

Mary: I’m not sure, but we don’t want the remote to have to 
know the specifics of the vendor classes. 

Sue: What do you mean? 

Mary: We don’t want the remote to consist of a set of if 
statements, like “if slotl == Light, then light. onO, else if slotl = 
Hottub then hottub.jetsOnO”. We know that is a bad design. 

Sue: I agree. Whenever a new vendor class comes out, we’d have 
to go in and modify the code, potentially creating bugs and more 
work for ourselves! 
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Hey, I couldn’t help 、 
overhearing. Since Chapter 1 ^ 
I’ve been boning up on Design 
Patterns. There's a pattern 
called ''Command Pattern” I think 
might help. ^ 


Mary: Yeah? Tell us more. 

Joe: The Command Pattern allows you to decouple the requester of an action 
from the object that actually performs the action. So, here the requester would be 
the remote control and the object that performs the action would be an instance 
of one of your vendor classes. 

Sue: How is that possible? How can we decouple them? After all, when I press a 
button, the remote has to turn on a light. 

Joe: You can do that by introducing “command objects” into your design. A 
command object encapsulates a request to do something (like turn on a light) on 
a specific object (say，the living room light object). So, if we store a command 
object for each button, when the button is pressed we ask the command object to 
do some work. The remote doesn’t have any idea what the work is, it just has a 
command object that knows how to talk to the right object to get the work done. 
So, you see, the remote is decoupled from the light object! 

Sue: This certainly sounds like it’s going in the right direction. 

Mary: Still, I’m having a hard time wrapping my head around the pattern. 

Joe: Given that the objects are so decoupled, it’s a little difficult to picture how the 
pattern actually works. 

Mary: Let me see if I at least have the right idea: using this pattern we, could 
create an API in which these command objects can be loaded into button 
slots, allowing the remote code to stay very simple. And, the command objects 
encapsulate how to do a home automation task along with the object that needs 
to do it. 

Joe: Yes, I think so. I also think this pattern can help you with that Undo button, 
but I haven’t studied that part yet. 

Mary: This sounds really encouraging, but I think I have a bit of work to do to 
really cc get’’ the pattern. 

Sue: Me too. 
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Meanwhile, back at the 

f A brief introduction to the Command Pattern 


So, let’s take a short detour back to the diner and study the interactions 
between the customers, the waitress, the orders and the short-order 
cook. Through these interactions, you’re going to understand the 
objects involved in the Command Pattern and also get a feel for how 
the decoupling works. After that, we’re going to knock out that remote 
control API. 

Checking in at the Objectville Diner... 



As Joe said, it is a little hard to understand the Command Pattern by just hearing 
its description. But don’t fear，we have some friends ready to help: 
remember our friendly diner from Chapter 1? It’s been a while since we 
visited Alice, Flo, and the short-order cook, but we’ve got good reason 
for returning (well, beyond the food and great conversation): the diner is 
going to help us understand the Command Pattern. 


Okay，we all know how the Diner operates: 



The Waitress 
takes the Order , 
places it on the 
order counter 
and says “Order 
up !，， 


❺ The Short-Order Cook prepares your meal 
from the Order. 
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the diner 


Let's study the interaction in a little more detail 

...and given this Diner is in Objectville, let’s think 
about the object and method calls involved, too! 
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The Objectville V'rnr roles awd responsibilities 


An Order Slip encapsulates a request to prepare a meal. 


Think of the Order Slip as an object，an object that acts__ 
as a request to prepare a meal. Like any object, it can be 
passed around - from the Waitress to the order counter, or to the 
next Waitress taking over her shift. It has an interface that consists 
of only one method, orderUpO, that encapsulates the actions 
needed to prepare the meal. It also has a reference to the object 
that needs to prepare it (in our case, the Cook). It’s encapsulated 
in that the Waitress doesn’t have to know what’s in the order 
or even who prepares the meal; she only needs to pass the slip 
through the order window and call “Order up!” 




The Waitress’s job is to take Order Slips and 
invoke the orderUpO method on them. 





w °^ ^>ih, 


The Waitress has it easy: take an order from the customer, 
continue helping customers until she makes it back to the 
order counter, then invoke the orderUp() method to have ) 
the meal prepared. As we’ve already discussed, in Objectville, the 
Waitress really isn’t worried about what’s on the order or who is going to 
prepare it; she just knows order slips have an orderUpO method she can 
call to get the job done. 

Now, throughout the day, the Waitress’s takeOrderO method gets 
parameterized with different order slips from different customers, but 
that doesn’t phase her; she knows all Order slips support the orderUpO 
method and she can call orderUpQ any time she needs a meal prepared. 


Don’t ask me to cook, 

I just take orders and 
yell ’’Order up!" 



The Short Order Cook has the knowledge 
required to prepare the meal. 

The Short Order Cook is the object that really knows 
how to prepare meals. Once the Waitress has invoked 
the orderUpO method; the Short Order Cook takes over and 
implements all the methods that are needed to create meals. 
Notice the Waitress and the Cook are totally decoupled: the 
Waitress has Order Slips that encapsulate the details of the 
meal; she just calls a method on each order to get it prepared. 
Likewise, the Cook gets his instructions from the Order Slip; he 
never needs to directly communicate with the Waitress. 
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the diner is a model for command pattern 



Okay, we have a 
Diner with a Waitress who is 
decoupled from the Cook by an 
Order Slip, so what? Get to 
the point! 


Patience, we’re getting there... 

Think of the Diner as a model for an OO design pattern that allows 
us to separate an object making a request from the objects that 
receive and execute those requests. For instance, in our remote 
control API, we need to separate the code that gets invoked when 
we press a button from the objects of the vendor-specific classes 
that carry out those requests. What if each slot of the remote held 
an object like the Diner’s order slip object? Then, when a button is 
pressed, we could just call the equivalent of the “orderUpO” method 
on this object and have the lights turn on without the remote 
knowing the details of how to make those things happen or what 
objects are making them happen. 

Now, let’s switch gears a bit and map all this Diner talk to the 
Command Pattern... 





Before we move on, spend some time studying 
the diagram two pages back along with Diner 
roles and responsibilities until you think you've 
got a handle on the Objectville Diner objects and 
relationships. Once you’ve done that, get ready 
to nail the Command Pattern! 
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From the Piwerto the Command Pattern 

Okay, we’ve spent enough time in the Objectville Diner that we know all the 
personalities and their responsibilities quite well. Now we’re going to rework 
the Diner diagram to reflect the Command Pattern. You’ll see that all the 
players are the same; only the names have changed. 
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Loading the Invoker 

❶ The client creates a 
command object. 

A The client does a 
^ setCommand() to store 
the command object in 
the invoker. 


❺ 


Later... the client asks 
the invoker to execute 
the command. Note: 
as you’ll see later in 
the chapter, once the 
command is loaded into 
the invoker, it may be 
used and discarded, or 
it may remain and be 
used many times. 
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who does what? 



Waitress 

C^niniancl 

Stprt Order Cook 

execute 。 

orderUpO 

Client 

Order 

inVpker 

Customer 

RecelVer 

takeOrderO 

setC^ninisinclO 
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Our first command object 

Isn’t it about time we build our first command object? Let’s go ahead and write 
some code for the remote control. While we haven’t figured out how to design the 
remote control API yet, building a few things from the bottom up may help us... 



Implementing the Command interface 

First things first: all command objects implement the same interface, which 
consists of one method. In the Diner we called this method orderUpO ； however, 
we typically just use the name execute0- 

Here’s the Command interface: 

public interface Command { __ q. . 

public void execute () ; C ^ f'ccd is or»c rwc^od called 


Implementing a Command to turn a light on 


Now, let’s say you want to implement a command for turning a light on. 
Referring to our set of vendor classes, the light class has two methods: on() 
and oflQ. Here’s how you can implement this as a command: 



Light 


on() 

off() 


/ This is a dommahd ； so v/c heed *to 

J i 州 pkmovt "the Command ih'tcV'-fadC- 


public class LightOnCommand implements Command { 
Light light; 


public LightOnCommand(Light light) 
this.light = light; 



public void execute () 
light.on(); 


TU ^ 心社 : 

o,o -wd 

av-c 6 o^*tvollw^ 


TKc dons-tvud-kov- is passed tKc s\>cdi-fid 
li# 七 tKat tWis dommand is go'mg -to 
don-tvol - say living V-OOW li 吵七 
一 and s-tas^cs it m I •吵七 msiandc 

vdvidblc- tailed ， 七 his 

is li# 七 objed-t is gomg io be 

Ac Rcdcivcv O-f VC<\UCS-t. 


Now that you’ve got a LightOnCommand class, let’s see if we can put it to use... 
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Using the command object 


Okay ， let’s make things simple: say we’ve got a remote control with only one 
button and corresponding slot to hold a device to control: 


public class SimpleRemoteControl { 
Command slot; 々 

public SimpleRemoteControl() {} 


public void setCommand(Command command) 
slot = command; 

} 

public void buttonWasPressed() { 

slot.execute(); 

} 


,, ,slo-t -to UA 

V.1I devite . 

Wc Kavc a wrt^od -fov sc-ttmg 
■tKc to^ar\d slo-t is gomg 
to don-tv-ol- This dould be dallcd 
-tirwCS i-f i\\t 

■tv>is todc vjar\icd io tKanjc 
bcV>aviov o( rcmoic button. 

4。“ tailed wheh ihe 

is P^»ed. All w e do is-bke 

5 i^ en i donirnarid b ound ^ ihe 
slot a«d call iis exeduieO ^eihod. 


TW»s \s ouv 


Creating a simple test to use the Remote Control 

Here 5 s just a bit of code to test out the simple remote control. Let’s take a look and 
we’ll point out how the pieces match the Command Pattern diagram: 

一 dP 伽 〆〆 i ,. 

cl,e t / 丁一士 — 一 

,-t Y.\ll ?a sseda 

public class RemoteControlTest { \ olojctt ^ 

public static void main(String[] args) { ^ b e «sed to ^ 代 1 ^ £ 士 . 

SimpleRemoteControl remote = new SimpleRemoteControl(); 

Light light = new Light () ; - Kov/ v/c trthkt S L • 丨少 t 

LightOnCommand lightOn = new LightOnCommand(light) ; objed-t, *tV>is will be ttc 

' Rctcivcv* o( *tV>c vc^ucs-t- 

remote.setCommand(lightOn); 
remote.buttonWasPressed(); 、 


Hcv-c, dv-catc a Command and 

pass tKc Rcdcivcv io it 


/\nd -tKcn vjc simula-tc -tKc 
button bc'mj pvessed- 


Weve, pass -the to^ A 
"to the /hvokev. 


Hcvcs i\\t out'p'A-t 
yuwnr\^ test Code! 


File Edit Window Help DinerFoodYum 


% java RemoteControlTest 
Light is On 
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;Sharpen your pencil 


Okay, it’s time for you to implement the 

GarageDoorOpenCommand class. First，supply the code for 
the class below. You 5 ll need the GarageDoor class diagram. -- 


public class GarageDoorOpenCommand 
implements Command { 


GarageDoor 

up() 

down() 

stop() 

Iight0n() 

Iight0ff() 



Yo»v tod« V'tve 


Now that you’ve got your class，what is the output of the following 
code? (Hint: the GarageDoor up() method prints out “Garage Door is 
Open” when it is complete.) 


public class RemoteControlTest { 

public static void main(String[] args) { 

SimpleRemoteControl remote = new SimpleRemoteControl(); 
Light light = new Light (); 

GarageDoor garageDoor = new GarageDoor(); 

LightOnCommand lightOn = new LightOnCommand(light); 
GarageDoorOpenCommand garageOpen = 

new GarageDoorOpenCommand(garageDoor); 


remote.setCommand(lightOn); 
remote.buttonWasPressed(); 
remote.setCommand(garageOpen); 
remote.buttonWasPressed(); 

} 




File Edit Window Help GreenEqqs&Ham 


% java RemoteControlTest 


n/ouv ou 切 u 七 V>c' 
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The Command Pattern defined 

You’ve done your time in the Objectville Diner, you’ve partly 
implemented the remote control API, and in the process you’ve 
got a fairly good picture of how the classes and objects interact in 
the Command Pattern. Now we’re going to define the Command 
Pattern and nail down all the details. 

Let’s start with its official definition: 


The Command Pattern encapsulates a request as an 
object, thereby letting you parameterize other objects 
with different requests, queue or log requests, and support 
undoable operations. 


Let’s step through this. We know that a command object 
encapsulates a request by binding together a set of actions on a 
specific receiver. To achieve this, it packages the actions and the 
receiver up into an object that exposes just one method, executeQ. 
When called, execute0 causes the actions to be invoked on the 
receiver. From the outside, no other objects really know what 
actions get performed on what receiver; they just know that if they 
call the executeO method, their request will be serviced. 

We’ve also seen a couple examples of parameterizing an object with 
a command. Back at the diner, the Waitress was parameterized 
with multiple orders throughout the day. In the simple remote 
control, we first loaded the button slot with a “light on” command 
and then later replaced it with a “garage door open” command. 
Like the Waitress, your remote slot didn’t care what command 
object it had, as long as it implemented the Command interface. 

What we haven’t encountered yet is using commands to 
implement queues and logs and support undo operations. Don’t worry, 
those are pretty straightforward extensions of the basic Command 
Pattern and we will get to them soon. We can also easily support 
what’s known as the Meta Command Pattern once we have the 
basics in place. The Meta Command Pattern allows you to create 
macros of commands so that you can execute multiple commands 
at once. 






mvokcv 一 "fov \Y\siar\tt 
slot o-f v-cmotc 
- tan be ^ 
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The Command Pattern defined: 
the class diagram 


n e a 山呼十 ^ 
t , e atrn 5 a CouMo^A a«d 
'."b Rc«Wffr. 


TKc (hvokev holds 


a dommahd ahd a-k 

some point asks iKc 


dommdhd "to dav*v*y 
ou-t a v-c^ucs*t by 
dall'mj i*ts cxcdutcO 

method- 



Command detlam W all h 

V ou alveadv k^, a 一 ar>d is ■⑽ oked 七广 —^ 
\^icO L e Uod,w^asba 代 “ 广七。 广 

at W. Vou-|laUo«ote^ -doU 







How does the design of the Command Pattern support the decoupling of the invoker of a 
request and the receiver of the request? 
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where do we begin? 



Mary: Me too. So where do we begin? 

Sue: Like we did in the SimpleRemote, we need to provide a way 
to assign commands to slots. In our case we have seven slots, each 
with an “on” and “off” button. So we might assign commands to 
the remote something like this: 

onCommands [ 0 ] = onConunand; 
offCommands[0] = offCommand; 

Mary: That makes sense, except for the Light objects. How does 
the remote know the living room from the kitchen light? 

Sue: Ah, that’s just it, it doesn’t! The remote doesn’t know 
anything but how to call execute0 on the corresponding 
command object when a button is pressed. 

Mary: Yeah, I sorta got that, but in the implementation, how do 
we make sure the right objects are turning on and off the right 
devices? 

Sue: When we create the commands to be loaded into the 
remote, we create one LightCommand that is bound to the living 
room light object and another that is bound to the kitchen light 
object. Remember, the receiver of the request gets bound to 
the command it’s encapsulated in. So, by the time the button 
is pressed, no one cares which light is which, the right thing just 
happens when the executeO method is called. 

Mary: I think I’ve got it. Let’s implement the remote and I think 
this will get clearer! 

Sue: Sounds good. Let’s give it a shot... 
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Assigning Commands to slots 

So we have a plan: We’re going to assign each slot to a command in 
the remote control. This makes the remote control our invoker. When 
a button is pressed the executeO method is going to be called on the 
corresponding command, which results in actions being invoked on the 
receiver (like lights, ceiling fans, stereos). 


(I) EadK slo-t 5C-U a 
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Implementing the Remote Control 


public class RemoteControl 
Command[] onCommands; 
Command[] offCommands; 


TW.S time av-ourvd vcmoic .s 50^3 to 
/ / V^a^lc seven Orv ^ 

^ “lUold m tov-ves^ond'm^ a 叫 s. 


I 於 "the fcons-tvu^-tov* all y/C r\ttd "to do is 
ms-ta^-tiatc dr\d mi-tializ^ tKc on and o-f-f 
av-v-ays. 

for (int i = 0; i < 7; i++) { 
onCommands[i] = noCommand; 
offCommands[i] = noCommand; 

} 


public RemoteControl() { 

onCommands = new Command[7]; 
offCommands = new Command[7]; 


9 


Command noCommand = new NoCommand() 


public void setCommand(int slot, Command onCommand, Command offCommand) { 
onCommands [slot] = onCommand; 

offCommands [slot] = offCommand; ^ T^c sciComma^dO method takes a slot position 

J ^ and an 0v\ ar\d 0(( Command io be s-tov-cd m 

七^^七 slot I 七 \>»A"ts -tKcsc ^omma^ds m ttc on and 

public void onButtonWasPushed(int slot) { o-f-f avvays -fov laicv- use- 

onCommands[slot].execute(); 


public void offButtonWasPushed(int slot) 
offCommands[slot].execute(); 



l/Vhch 0v\ ov- 0(( bu*bto 外 is 

fvessed, iKc Kav-dv/av-c -takes 
dav-c o-f dallihj iKc dov-v-espo^dihj 
mctKods ohBu-t-tohlVasPusKcdO ov- 
o-f-fBu-tiohlVasPusKcdO. 


public String toString() { 

StringBuffer stringBuff = new StringBuffer(); 

stringBuff.append (''\n - Remote Control - \n"); 

for (int i = 0; i < onCommands.length; i++) { 

stringBuf f. append ('' [slot '、+ i + '、] '' + onCommands [i] .getClassO .getNameO 
+ '、 '、+ of f Commands [i] .getClassO .getNameO + 、 '\n"); 

} 

return stringBuff.toString(); 

} overwritten toStvmgO io out c adK slot a^d its 

doirircspohdihg 6o_ahd. /ou || SCC us use this y/Kch y/c test "the 
VCrwo-tc dorrtvol. 
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Implementing the Commands 


Well, we’ve already gotten our feet wet implementing the LightOnCommand for 
the SimpleRemoteControl. We can plug that same code in here and everything 
works beautifully. Off commands are no different; in fact the LightOfTCommand 
looks like this: 


public class LightOffCommand implements Command { 
Light light; 


public LightOffCommand(Light light) { 
this.light 二 light; 


public void execute () 
light.off(); 



TKc LijK"tOWCommay/ovks oca^-tly 
same v/ay as LijK-tOnCommand, 
cx-dcj^-t avc b'md'mj -t^c vcdcivcv 

{jo a 沉七 icm: -tKc o^-fO mctKod- 


Let’s try something a little more challenging; how about writing on and off 
commands for the Stereo? Okay, off is easy, we just bind the Stereo to the off() 
method in the StereoOffCommand. On is a little more complicated; let’s say we 
want to write a StereoOnWithCDCommand... 


public class StereoOnWithCDCommand implements Command { 
Stereo stereo; 


Stereo 

on() 

off() 

setCd() 

setDvd() 

setRadio() 

setVolume() 


public StereoOnWithCDCommand(Stereo stereo) { 


this.stereo = stereo; 


public void execute() { 

stereo.on(); 



Oust like tv>e L'^VitOirvCommairvd, 'Nt 
说 d 恤 ■ 时 ■Ute oUk 如 w i 
ave 5 oi «5 to be t 。 士。 11 岣 批 stove 

it in a lo£al ms-ta«te vaviable. 


stereo.setCD(); 
stereo.setVolume(11); 



To dairry oui ihis y/e ne ed io call 

«>«ihods ov, the siereo ： f iysi, iuy n ii on> iher, sei 
iUo play 心 CD, 扣 d kally se Uh e volume -to II. 
w^y II? Well, i-t's bft-tev -thaw lO, y 吵 t? 


Not too bad. Take a look at the rest of the vendor classes; by now, you can definitely 
knock out the rest of the Command classes we need for those. 
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Putting the Remote Control through its paces 

Our job with the remote is pretty much done; all we need to do is run some tests and 
get some documentation together to describe the API. Home Automation or Bust, 
Inc. sure is going to be impressed, don’t you think? We’ve managed to come up with 
a design that is going to allow them to produce a remote that is easy to maintain 
and they’re going to have no trouble convincing the vendors to write some simple 
command classes in the future since they are so easy to write. 

Let’s get to testing this code! 

public class RemoteLoader { 

public static void main(String[] args) { 

RemoteControl remoteControl = new RemoteControl(); 


Light livingRoomLight = new Light (''Living Room 〃）； 
Light kitchenLight = new Light (''Kitchen"); 

CeilingFan ceilingFan= new CeilingFan (''Living Room 〃）； 
GarageDoor garageDoor = new GarageDoor ('、"）； 

Stereo stereo = new Stereo (''Living Room"); 



Create all 

■tW»v m UaW 


LightOnCommand livingRoomLightOn = 

new LightOnCommand(livingRoomLight); 

LightOffCommand livingRoomLightOff = 

new LightOffCommand(livingRoomLight); 

LightOnCommand kitchenLightOn = 

new LightOnCommand(kitchenLight); 

LightOffCommand kitchenLightOff = 

new LightOffCommand(kitchenLight); 



Cvca-tc all iKc LigK-t 

Command objed*ts. 


CeilingFanOnCommand ceilingFanOn = 

new CeilingFanOnCommand(ceilingFan); 
CeilingFanOffCommand ceilingFanOff = 

new CeilingFanOffCommand(ceilingFan); 


Jfor tC.»Vur^ 狀 . 


GarageDoorUpCommand garageDoorUp = 

new GarageDoorUpCommand(garageDoor); 
GarageDoorDownCommand garageDoorDown = 

new GarageDoorDownCommand(garageDoor), 


Cvcatc ttc a^d 

Commands $av*ay. 


StereoOnWithCDCommand stereoOnWithCD = 

new StereoOnWithCDCommand(stereo); 
StereoOffCommand stereoOff = 

new StereoOffCommand(stereo); 


Cvcatc stevco 0^ 
0-f-f d.ommar'ds. 


m 
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remoteControl.setCommand(0 , livingRoomLightOn, livingRoomLightOff); 
remoteControl.setCommand(1, kitchenLightOn, kitchenLightOff); j 
remoteControl.setCommand(2 , ceilingFanOn, ceilingFanOff); A 
remoteControl.setCommand(3, stereoOnWithCD, stereoOff); / . 


System.out.printIn(remoteControl); 


remoteControl 

remoteControl 

remoteControl 

remoteControl 

remoteControl 

remoteControl 

remoteControl 

remoteControl 


.onButtonWasPushed(0); 

.offButtonWasPushed(0); 
. onButtonWasPushed(1); 

. offButtonWasPushed(1); 
.onButtonWasPushed(2); 

. offButtonWasPushed(2); 
.onButtonWasPushed(3); 

.offButtonWasPushed(3); 


!^o\i -that v/c’vc got 
dll ouv domrwahds； v/C 
匕 load "thcrw i»vto 
VCrwo-tc slots. 


tw’s we use ou*- ioSi*-i h gO 

铋 pirihi each v en ,oie slo^ a^d 
七 he to^and 七 ha 七 i 七 is assigned io. 


All irigh-t, we are iready -to toll/ 
Now, we step ikowgh each slo-t 
and push i-ts On and 0U button. 


Now, let^ check oot the execution of our remote control test.. 


File Edit Window Help CommandsGetThingsDone 


% java RemoteLoader 

- Remote Control - 

[slot 0] headfirst.command.remote.LightOnCommand headfirst 

[slot 1] headfirst.command.remote.LightOnCommand headfirst 

[slot 2] headfirst.command.remote.CeilingFanOnCommand headfirst 
[slot 3] headfirst.command.remote.StereoOnWithCDCommand headfirst 
[slot 4] headfirst.command.remote.NoCommand headfirst 

[slot 5] headfirst.command.remote.NoCommand headfirst 

[slot 6] headfirst.command.remote.NoCommand KT headfirst 


.command.remote.LightOffCommand 
.command.remote.LightOffCommand 
.command.remote.CeilingFanOffCommand 
.command.remote.StereoOffCommand 
.command.remote.NoCommand 
.command.remote.NoCommand 
.command.remote.NoCommand 


Living Room light is on 

Living Room light is off 

Kitchen light is on 

Kitchen light is off 

Living Room ceiling fan is on high 

Living Room ceiling fan is off 

Living Room stereo is on 

Living Room stereo is set for CD input 

Living Room Stereo volume set to 11 

Living Room stereo is off 


仏 slots 0(( Slo^s 


^ 仏峰 ahds m athoJ Rcmcmbcv -； -the ou-tpu-t 
dcvi ^ Hornes 心咖七 k vc^dov dlasscs. 
FV v/hen a light object is 咖 i 七 

pviirts Living Room lijK-t is on- W 









null object 



Command noCommand = new NoCommand(); 
for (int i = 0; i < 7; i++) { 
onCommands[i] = noCommand; 
offCommands[i] = noCommand; 

} 

So in the output of our test run, you are seeing slots that haven’t been 
assigned to a command, other than the default NoCommand object 
which we assigned when we created the RemoteControl. 



Pattern 

Honorable 

Mention 


The NoCommand object is an example of a null object. A null object is useful 
when you don’t have a meaningful object to return, and yet you want to remove 
the responsibility for handling null from the client. For instance, in our remote 
control we didn’t have a meaningful object to assign to each slot out of the box, 
so we provided a NoCommand object that acts as a surrogate and does nothing 
when its execute method is called. 


You’ll find uses for Null Objects in conjunction with many Design Patterns and 
sometimes you’ll even see Null Object listed as a Design Pattern. 
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三三匕 ======= 

Jhe remote as well as drastically reduce your ongoing maintenance cos s. 

The following class diagram provides an overview of our design: 

I The RemoteControl manages a set of Command 
objects, one per button. When a button is pressed, 
the corresponding ButtonWasPushedO method is 
called, which invokes the execute。method on the 

_ _ _ command. That is the full extent of the remotes _ _ 

I The RemoteLoader creates a knowledge of the classes it，s invoking as the All RemoteControl commands 

number of Command Objects Command object decouples the ? mote implement the Command 

that are loaded into the slots classes doing the actual home-automation work. | interface , wh ich consists of one 

— - I __ . I I _anH Q 


The RemoteLoader creates a 
number of Command Objects 
that are loaded into the slots 
of the Remote Control. Each 
command object encapsulates 
a request of a home 
automation device. 


I All RemoteControl commands 
implement the Command 
interface, which consists of one 
method: executeO. Commands 
encapsulate a set of actions 
on a specific vendor class. The 
remote invokes these actions by 
calling the executeO method. 


RemoteLoader 


RemoteControl 

onCommands 

offCommands_ 

setCommandO 

onButtonWasPushed() 

offButtonWasPushed() 


LightOnComm 


LightOffCommand 

__ —-- 

3 …… .： 

executeO . 


1 …. n __ 


public void execute(){ ■ 

/ 


- - -—— 

public void executeO { 
light, off () 


The Vendor Classes are used to perform 
the actual home-automation work of 
I controlling devices. Here, we are using the 
Light class as an example. 


Using the Command Interface, each action that can be 
invoked by pressing a button on the remote's'mplemented 
with a simple Command object. The Command Objec holds 
a reference to an object that is an instance of a Vendor Class 
andTmplementsan execute m ethod that calls one or more 

methods on that object. Here we show two such classes 
that turn a light on and off, respectively.__ 
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don’t forget undo 


Great job; it looks like 
you’ve come up with a terrific design, 
but aren't you forgetting one little thing 
the customer asked for? 

LIKE THE UNDO BUTTON!!!! 


Whoops! We almost forgot... luckily, once we 
have our basic Command classes, undo is easy 
to add. Let’s step through adding undo to our 
commands and to the remote control... 



What are we doing? 

Okay, we need to add functionality to support the undo button on the remote. It works like 
this: say the Living Room Light is off and you press the on button on the remote. Obviously 
the light turns on. Now if you press the undo button then the last action will be reversed — in 
this case the light will turn off. Before we get into more complex examples, let’s get the light 
working with the undo button: 


When commands support undo, they have an undo() method that mirrors the executef) 
method. Whatever execute。last did, undoO reverses. So, before we can add undo to our 
commands, we need to add an undoO method to the Command interface: 

public interface Command { 
public void execute(); 
public void undo(); 

} Hcirc's -the new uhdoO method. 

That was simple enough. 

Now, let’s dive into the Light command and implement the undoQ method. 
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Let’s start with the LightOnCommand: if the LightOnCommand’s executeO method 
was called, then the onQ method was last called. We know that undo。needs to do the 
opposite of this by calling the offQ method. 


public class LightOnCommand implements Command { 
Light light; 


public LightOnCommand(Light light) { 
this.light = light; 


public void execute() { 

light.on(); 


public void undo() { 
light.off(); 





Piece of cake! Now for the LightOfTCommand. Here the undo() method just 
needs to call the Light’s onQ method. 


public class LightOffCommand implements Command { 
Light light; 


public LightOffCommand(Light light) { 
this.light = light; 


public void execute() { 

light.off(); 


} 


public void undo() 
light.on(); 

} 




Y\S 


Could this be any easier? Okay, we aren’t done yet; we need to work a little 
support into the Remote Control to handle tracking the last button pressed 
and the undo button press. 
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To add support for the undo button we only have to make a few small changes to the Remote 
Control class. Here’s how we’re going to do it: we’ll add a new instance variable to track the 
last command invoked; then, whenever the undo button is pressed, we retrieve that command 
and invoke its undoQ method. 


public class RemoteControlWithUndo { 
Command[] onCommands; 

Command[] offCommands; 

Command undoCommand; 



TWs is WIUW 如 UsUo-ad 

U -tv, e u«do Wttor,. 


public RemoteControlWithUndo() { 
onCommands = new Command[7]; 
offCommands = new Command[7]; 


Command noCommand = new NoCommand(); 
for (int i=0;i<7;i++) { 

onCommands[i] = noCommand; 
offCommands[i] = noCommand; 

} 

undoCommand = noCommand; 


Jus-t like -the o-thev- slots ； uhdo 
stairts M With a KoCommahd ； s 
pvcss'mj Uhdo bc-fov-c a^y o-thev* 
button wor> ; -t do ahy-th'mg ai all. 


public void setCommand(int slot. Command onCommand, 
onCommands[slot] = onCommand; 
offCommands[slot] = offCommand; 

} 


Command offCommand) { 


public void onButtonWasPushed(int slot) { 
onCommands[slot].execute(); 
undoCommand = onCommands[slot]; 

} 

public void offButtonWasPushed(int slot) 
offCommands[slot].execute(); 
undoCommand = offCommands[slot]; 

} 

public void undoButtonWasPushed() { 

undoCommand.undo(); 

} 

public String toString() { 

// toString code here... 

} 



a button is yessed, take 

it; save a vc-fcvc^c b> 

|七 m "UiC undoCorww»and 
vaviablc- Wc do iKis -fov- botv/'em 
Commands and w oW w 


iVKch -tKc uhdo button is pressed, v/c 
invoke "tKc UhdoO method o-f -tKc 
dommdhd s-toved ih UhdoCommdhd- 
TKis vcvcvscs -tKc o^evaiioh o( -tKc 
Ids-t dommShd c^-c^u-tcd- 
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Time to QA that Undo button! 

Okay, let’s rework the test harness a bit to test the undo button: 
public class RemoteLoader { 


public static void main(String[] args) { 


RemoteControlWithUndo remoteControl = new RemoteControlWithUndo(); 


Light livingRoomLight = new Light (''Living Room"); 


LightOnCommand livingRoomLightOn = 

new LightOnCommand(livingRoomLight); 
LightOffCommand livingRoomLightOff = 

new LightOffCommand(livingRoomLight); 



S ⑽二 r c : 二 


remoteControl.setCommand(0, livingRoomLightOn, livingRoomLightOff); 


remoteControl.onButtonWasPushed(0); 
remoteControl.offButtonWasPushed(0); 
System.out.println(remoteControl); 
remoteControl.undoButtonWasPushed(); 
remoteControl.offButtonWasPushed(0); 
remoteControl.onButtonWasPushed(0); 
System.out.println(remoteControl); 
remoteControl.undoButtonWasPushed(); 


C. Md the lijK-t Con\m^y\ds 

"to "tKc vcmo-tc m slot O. 

Tuv-h *thc lijK-t oy \, *tKcr» 

<>f-f *tKch uhdo- 


‘The 〜 iwryx ihc light off, badk Oh and undo. 


And here 5 s the test results... 


File Edit Window Help UndoCommandsDefyEntropy 


% java RemoteLoader 

Light is on v 

Light is off 


Twrv\ -the on, "thch o^-p. 


- Remote Control - 匕 

[slot 0] headfirst.command.undo.LightOnCommand 


s -the Li^h-t dorwm^ds. 

headfirst. command. undo. LightOff Command 


[slot 1] headfirst.command.undo.NoCommand headfirst.command.undo.NoCommand 
[slot 2] headfirst.command.undo.NoCommand headfirst.command.undo.NoCommand 
[slot 3] headfirst.command.undo.NoCommand headfirst.command.undo.NoCommand 
[slot 4] headfirst. command.undo .NoCommand headfirst. command. undo.NoCommand 
[slot 5] headfirst.command.undo.NoCommand headfirst.command.undo.NoCommand 
[slot 6] headfirst.command.undo.NoCommand headfirst.command.undo.NoCommand 
[undo] headfirst. command. undo. LightOff Command ^ Kow undo holds -the 

Light is on 〆 Wdo was jessed... -the U^iOUCo^a^d U^ioUCo^a^d, -the Iasi 
州 doO iutrM ihc back or». mvoked- 

Light is off 

Light is on ^ ^ TKew v/e "tuv-h -tKe or-r badk ov\- 


- Remote Control - 

[slot 0] headfirst. command. undo. LightOnCommand headfirst. command, undo. LightOff Command 

[slot 1] headfirst.command.undo.NoCommand headfirst.command.undo.NoCommand 

[slot 2] headfirst.command.undo.NoCommand headfirst.command.undo.NoCommand 

[slot 3] headfirst.command.undo.NoCommand headfirst.command.undo.NoCommand 

[slot 4] headfirst.command.undo.NoCommand headfirst.command.undo.NoCommand 

[slot 5] headfirst.command.undo.NoCommand headfirst.command.undo.NoCommand 


[slot 6] headfirst.command.undo.NoCommand headfirst.command.undo.NoCommand 


[undo] headfirst.command.undo.LightOnCommand 
Light is off Undo was fvessed, 七 he I 吵七 is badk o^-f. 


冰 do holds ihe U^iOXo^ar^d, -the Iasi 
Command invoked. 
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we need to keep some state for undo 


Using state to implement Undo 


Okay，implementing undo on the Light was instructive but a little too easy. Typically, 
we need to manage a bit of state to implement undo. Let’s try something a little more 
interesting, like the CeilingFan from the vendor classes. The ceiling fan allows a 
number of speeds to be set along with an off method. 

Here’s the source code for the CeilingFan: 



public class CeilingFan { 

public static final int HIGH = 3; 
public static final int MEDIUM = 2; 
public static final int LOW = 1 ; 
public static final int OFF = 0; 
String location; 
int speed; 








public CeilingFan(String location) 
this.location = location; 
speed = OFF; 

} 

public void high() { 
speed = HIGH; 

// code to set fan to high 

} 

public void medium() { 
speed = MEDIUM; 

// code to set fan to medium 

} 

public void low() { 
speed = LOW; 

// code to set fan to low 

} 


Hmm, so to properly 
implement undo, I’d have 
to take the previous speed of 
the ceiling fan into account.. 


TKcsc mctKods set "tKc 
speed of -tKc dcil'mj 



public void off() { 
speed = OFF; 

// code to turn fan off 

} 

public int getSpeed() { 
return speed; 

} ^ 




二”柳 ed0 . 
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Adding Undo to the ceiling faw commands 

Now let’s tackle adding undo to the various CeilingFan commands. To 
do so, we need to track the last speed setting of the fan and, if the undoO 
method is called, restore the fan to its previous setting. Here’s the code for 
the C eilingFanHighC ommand: 



public class CeilingFanHighCommand implements Command { 
CeilingFan ceilingFan; 
int prevSpeed; 

public CeilingFanHighCommand(CeilingFan CeilingFan) 
this.CeilingFan = CeilingFan; 

} 




public void execute() { 

prevSpeed = CeilingFan.getSpeed(); 
CeilingFan.high(); 

} 



In oecdu-tc, bc-fovc wc 
■tKc o( -tKc -fan, wc 

i\ttA bo -firs-t rctovd i-ts 
^vcvious s-fcd-tc, just m y/c 
need {jo undo ouv a^tioy\s. 


public void undo() { 

if (prevSpeed == CeilingFan. HIGH) { 

CeilingFan.high(); 

} else if (prevSpeed == 

CeilingFan. MEDIUM) { 

CeilingFan.medium() 

r 

} else if (prevSpeed == 

CeilingFan.LOW) { 

CeilingFan.low(); 

} else if (prevSpeed == 

CeilingFan.OFF) { 

CeilingFan.off(); 

} 

} 



一 - wc sei -tKc speed 

^ -Pah b 把 k £ 0 七 
previous speed. 





We’ve got three more ceiling fan commands to write: low, medium, and off. Can you see 
how these are implemented? 
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test the ceiling fan 


fret ready to test the ceiling faw 

Time to load up our remote control with the ceiling fan 
commands. We’re going to load slot zero’s on button with 
the medium setting for the fan and slot one with the high 
setting. Both corresponding off buttons will hold the ceiling 
fan off command. 

Here’s our test script: 



public class RemoteLoader { 



public static void main(String[] args) { 

RemoteControlWithUndo remoteControl = new RemoteControlWithUndo(); 


CeilingFan ceilingFan = new CeilingFan (''Living Room"); 


CeilingFanMediumCommand ceilingFanMedium = 

new CeilingFanMediumCommand(ceilingFan) 
CeilingFanHighCommand ceilingFanHigh = 

new CeilingFanHighCommand(ceilingFan); 
CeilingFanOffCommand ceilingFanOff = 

new CeilingFanOffCommand(ceilingFan); 


remoteControl.setCommand(0, 
remoteControl.setCommand(1, 


ceilingFanMedium, CeilingFanOff) 
ceilingFanHigh, CeilingFanOff); 




ttcv*c >/C ?认七 medium m 

slo 七 zjCv-o, W 吵 … 

slo-t iA/c also load 


remoteControl.onButtonWasPushed(0); 
remoteControl.offButtonWasPushed(0); 
System.out.println(remoteControl); 
remoteControl.undoButtonWasPushed(); 

remoteControl.onButtonWasPushed(1); 
System.out.println(remoteControl); 
remoteControl.undoButtonWasPushed(); 1 




piv-s-b, o” 

rt 

Undo! It Should 90 \>atV io medium … 

Tuvn \i io W13V) tWis ■time. 

A«d, o, e u«do ； it should 9 obadk to we di_. 
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Testing the ceiling fan... 


Okay, let’s fire up the remote, load it with commands, and push some buttons! 


File Edit Window Help UndoThis! 


% java RemoteLoader 

Living Room ceiling fan is on medium 
Living Room ceiling fan is off 


丁 wry» 七 he dcil'mj -fah oh 
medium, iKch tuv-h i*t off. 


- Remote Control - 

[slot 0] headfirst.command.undo.NoCommand 
[slot 1] 


l 


tteve ave tVie tommands 
m -tV^e vemo-t« … 


headfirst. command, undo. NoCommand 
headfirst. command. undo. Ce i 1 ingFanMediumCommand headfirst. command. undo. CeilingFanOf f- 


Command 
[slot 2] 
mand 
[slot 
[slot 
[slot 
[slot 


headfirst. command. undo. CeilingFanHighCommand headfirst. command. undo. CeilingFanOf fCom- 


3] 

4] 

5] 

6 ] 


headfirst. command, undo. NoCommand 
headfirst. command, undo. NoCommand 
headfirst. command, undo. NoCommand 
headfirst. command, undo. NoCommand 


headfirst. command, undo. NoCommand 
headfirst. command, undo. NoCommand 
headfirst. command, undo. NoCommand 
headfirst. command, undo. NoCommand 


[undo] headfirst.command.undo.CeilingFanOffCommand 


… and uhdo has -tKc las-t 
dommahd exedu-ted ； -the 
_ CcilmjFahO-fCommahd. 


Living Room ceiling fan is on medium 
Living Room ceiling fan is on high 


- U^do -tKc las-t dommartd ； i-b joes badk -to medium. 
、 Hovt, -tuv-h i-t OY\ high. 


- Remote Control - 

[slot 0] headfirst.command.undo.NoCommand headfirst.command.undo.NoCommand 

[slot 1] headfirst.command.undo.CeilingFanMediumCommand headfirst.command.undo.CeilingFanOff- 

Command 

[slot 2] headfirst.command.undo.CeilingFanHighCommand headfirst.command.undo.CeilingFanOffCom¬ 

mand 

headfirst. 
headfirst. 
headfirst. 
headfirst. 


[slot 3] headfirst. 
[slot 4] headfirst. 
[slot 5] headfirst. 
[slot 6] headfirst. 


command.undo.NoCommand 
command.undo.NoCommand 
command.undo.NoCommand 
command.undo.NoCommand 


.command.undo.NoCommand 
.command.undo.NoCommand 
.command.undo.NoCommand 
.command.undo.NoCommand 


[undo] headfirst.command.undo.CeilingFanHighCommand <C- 


Hovi, high is -the las-t 
dommahd 


Living Room ceiling fan is on medium 

% 


仏 c more Uhdo, ahd the -Fdh 

3 ocs tadk -fco medium speed- 
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macro commands 


Every remote needs a Party Mode! 

What’s the point of having a remote if you can’t 
push one button and have the lights dimmed, the 
stereo and TV turned on and set to a DVD and the 
hot tub fired up? 




kihd o-f Command "tha-t dah 


Commdhds... 

( more -than ohc o( i\)cJ 

\ (Vtty good idea ； huh? 




public class MacroCommand implements Command { 
Command[] commands; 


public MacroCommand(Command[] 
this.commands = commands; 

} 


commands) { 


s __ avv-ay o( 

Co^a^ds amd sW them the MatyoCo^aU 

public void execute() { 

for (int i = 0; i < commands.length; i++) { 
commands[i].execute(); 

} } 欠 '- 机作 — ">adiro ^eis eY.etuied by the rer^oie, 

execute "those dorwmahds Ohe a*t a -time. 
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Using a macro command 

Let’s step through how we use a macro command: 


First we create the set of commands we want to go into the macro: 


Light light = new Light (''Living Room"); 

TV tv = new TV (''Living Room ’’）； 

Stereo stereo = new Stereo (''Living Room"); 
Hottub hottub = new Hottub(); 


_ C^aic all -the devices ； a lijhi 
*tv, s-tcvco ； ahd \\oi -tub. 


LightOnCommand lightOn = new LightOnCommand(light); 
StereoOnCommand. stereoOn = new StereoOnCommand(stereo) 
TVOnCommand tvOn = new TVOnCommand(tv); 
HottubOnCommand hottubOn = new HottubOnCommand(hottub) 


Ko>n dveate all tv>e 

(^~ to to«tvol 



❺ 


Next we create two arrays, one for the On commands and one for the Off com¬ 
mands, and load them with the corresponding commands: 


Cveate a« avvav ^ 
arv avvay 

d.omrr»3»r\ds••• 


Command[] partyOn = { lightOn, stereoOn, tvOn, hottubOn}; 
Command[] partyOff = { lightOff, stereoOff, tvOff, hottubOff}; 


MacroCommand partyOnMacro = new MacroCommand (partyOn) ; ^_dveatc *tv/o 

MacroCommand partyOf fMacro = new MacroCommand (partyOff); 亡 ovvcspohdihg macros 

to Kold -them. 


❺ 


Then we assign MacroCommand to a button like we always do: 




remoteControl.setCommand(0, partyOnMacro, partyOffMacro); 


Assign *tKc madvo 
dommdhd "to 3 bu*t*totr» 3 S 
v/c would any dommahd- 
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Finally, we just need to push some buttons and see if this works. 


System.out.println(remoteControl); 


remoteControl.onButtonWasPushed(0); 


remoteControl.offButtonWasPushed(0); 



-the output 


I File Edit Window Help You Can'tBeatABabka 


% java RemoteLoader 

- Remote Control - 

[slot 0] headfirst.command.party.MacroCommand 
[slot 1] headfirst.command.party.NoCommand 
[slot 2] headfirst.command.party.NoCommand 
[slot 3] headfirst.command.party.NoCommand 
[slot 4] headfirst.command.party.NoCommand 
[slot 5] headfirst.command.party.NoCommand 
[slot 6] headfirst.command.party.NoCommand 


扞饮 c a 代七 k "Uo madv-o do_ahds. 

headfirst. command.party.MacroCommand 
headfirst. command, party. NoCommand 
headfirst. command, party. NoCommand 
headfirst. command, party. NoCommand 
headfirst. command, party. NoCommand 
headfirst. command, party. NoCommand 
headfirst. command, party. NoCommand 


[undo] headfirst.command.party.NoCommand 


- Pushing Macro On - 

Light is on 

Living Room stereo is on 
Living Room TV is on 

Living Room TV channel is set for DVD 
Hottub is heating to a steaming 104 degrees 
Hottub is bubbling! 


/\H tKc Commands m tKc ma^vo 
avc v/Kcn v/c invoke 

■tKc on matro... 


- Pushing Macro Off - 

Light is off 

Living Room stereo is off 

Living Room TV is off 

Hottub is cooling to 98 degrees 


ahd v/hch wc mvokc -the of-f 
madvo. Looks like i-t wovks. 
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The only thing our MacroCommand is missing its undo functionality. When the 
undo button is pressed after a macro command, all the commands that were invoked 
in the macro must undo their previous actions. Here’s the code for MacroCommand; 
go ahead and implement the undoQ method: 


public class MacroCommand implements Command { 
Command[] commands; 

public MacroCommand(Command[] commands) { 
this.commands = commands; 


public void execute() { 

for (int i = 0; i < commands.length; i++) { 
commands[i].execute(); 


public void undo() { 


Do I always need a receiver? 
Why can’t the command object 
implement the details of the 
executeO method? 

In general, we strive for "dumb" 
command objects that just invoke 
an action on a receiver; however, 
there are many examples of "smart” 
command objects that implement 
most, if not all, of the logic needed 
to carry out a request. Certainly 
you can do this; just keep in mind 
you’ll no longer have the same level 
of decoupling between the invoker 
and receiver, nor will you be able to 
parameterize your commands with 
receivers. 


l5iirnB 6 ^u©stiPiis 


How can I implement a history 
of undo operations? In other words, 

I want to be able to press the undo 
button multiple times. 

Great question! It’s pretty 
easy actually; instead of keeping just 
a reference to the last Command 
executed, you keep a stack of previous 
commands. Then, whenever undo is 
pressed, your invoker pops the first 
item off the stack and calls its undo() 
method. 


Could I have just implemented 
Party Mode as a Command by 
creating a PartyCommand and 
putting the calls to execute the other 
Commands in the PartyCommand’s 
execute)) method? 

You could; however, you’d 
essentially be "hardcoding’’the 
party mode into the PartyCommand. 
Why go to the trouble? With the 
MacroCommand, you can decide 
dynamically which Commands you 
want to go into the PartyCommand, 
so you have more flexibility using 
MacroCommands. In general, the 
MacroCommand is a more elegant 
solution and requires less new code. 
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queuing requests 


More uses of the Command Patterw: queuing requests 


Commands give us a way to package a piece of 
computation (a receiver and a set of actions) and pass it 
around as a first-class object. Now, the computation itself 
may be invoked long after some client application creates 
the command object. In fact, it may even be invoked by a 
different thread. We can take this scenario and apply it to 
many useful applications such as schedulers, thread pools 
and job queues, to name a few. 

Imagine a job queue: you add commands to the queue 
on one end, and on the other end sit a group of threads. 
Threads run the following script: they remove a command 
from the queue, call its executeO method, wait for the call 
to finish, then discard the command object and retrieve a 


TKvcSds VCmOVC 

•fvom i\\t OY\t by OY\t 

^all 

mc-tKod. Out Coptic, 
50 batk -fov a 

乙 ommd 灼 d object 


added to 


^,ca/ 


Commands 





(e.fcjleol^Dr 

^ayTrac^ 




' - - ■ - ；I ^ 


TWis ^ves us c-f-fcd-tWc v/ay 
-to limi-t dompu-tatio^ io a 
-f iy.cd ^umbev o-f -tKvcads. 


thread 


Threads computing 
jobs 



Note that the job queue classes are totally decoupled from the ob¬ 
jects that are doing the computation. One minute a thread may be 
computing a financial computation, and the next it may be retrieving 
something from the network. The job queue objects don’t care; they 
just retrieve commands and call executeO. Likewise, as long as you 
put objects into the queue that implement the Command Pattern, 
your executeO method will be invoked when a thread is available. 


私 …—— 

How might a web server make 
use of such a queue? What other 
applications can you think of? 
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More uses of the Command Patterw: logging requests 


The semantics of some applications require that we log all actions and be able to 
recover after a crash by reinvoking those actions. The Command Pattern can support 
these semantics with the addition of two methods: store Q and loadQ. In Java we could 


use object serialization to implement these methods, but the normal caveats for using 
serialization for persistence apply. 

How does this work? As we execute commands, we store a history of them on disk. 
When a crash occurs, we reload the command objects and invoke their executef) 
methods in batch and in order. f \ 

Now, this kind of logging wouldn’t make sense for a remote control; however, there 
are many applications that invoke actions on large data structures that can’t be quickly 
saved each time a change is made. By using logging, we can save all the operations 
since the last check point, and if there is a system failure, apply those operations to our 
checkpoint. Take, for example, a spreadsheet application: we might want to implement 
our failure recovery by logging the actions on the spreadsheet rather than writing a copy 
of the spreadsheet to disk every time a change occurs. In more advanced applications, 
these techniques can be extended to apply to sets of operations in a transactional 
manner so that all of the operations complete, or none of them do. 


<< interface» 


add tv/o methods 
-fov 1039^9- 



•is 

s-toved or\ d'»sk- 



/vf 七 cr a s'/stem hWrc ， 
七 objedts arc 

reloaded ar^a 

• m Uc toYYtti o^rdcr. 
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y^ur design toolbox 



Tools for your design Toolbox 

Your toolbox is starting to get heavy! In this chapter 
we’ve added a pattern that allows us to encapsulate 
methods into Command objects: store them, pass them 
around, and invoke them when you need them. 



BULLET POINTS 


■ The Command Pattern 
decouples an object, making 
a request from the one that 
knows how to perform it. 

■ A Command object is at the 
center of this decoupling and 
encapsulates a receiver with 
an action (or set of actions). 

■ An invoker makes a request of 
a Command object by calling 
its execute() method, which 
invokes those actions on the 
receiver. 

■ Invokers can be parameterized 
with Commands, even 
dynamically at runtime. 

■ Commands may support undo 
by implementing an undo 
method that restores the object 
to its previous state before 

the execute() method was last 
called. 

■ Macro Commands are a simple 
extension of Command that 
allow multiple commands to 

be invoked. Likewise, Macro 
Commands can easily support 
undo()_ 

■ In practice, it is not uncommon 
for “smart” Command objects 
to implement the request 
themselves rather than 
delegating to a receiver. 

■ Commands may also be used 
to implement logging and 
transactional systems. 
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Time to take a breather and let it aJl sink in. 

It’s another crossword; all of the solution words are from 
this chapter. 



Across 

3. The Waitress was one 

4. A command_a set of actions and a 

receiver 

7. Dr. Seuss diner food 

8. Our favorite city 

9. Act as the receivers in the remote control 

13. Object that knows the actions and the 
receiver 

14. Another thing Command can do 

15. Object that knows how to get things done 
17. A command encapsulates this 


Down 

1. Role of customer in the command pattern 

2. Our first command object controlled this 

5. Invoker and receiver are_ 

6. Company that got us word of mouth business 

10. All commands provide this 

11. The cook and this person were definitely 
decoupled 

12. Carries out a request 

16. Waitress didn't do this 


you are here ► 231 

















exercise solutions 



Exercise 


♦ 命 T + 

_ o 备 《 孓 - 

Match the diner objects and methods with the corresponding names from the 
Command Pattern 

Diner Command Pattern 


Solutions 



ConimancI 


©x©cut©0 


Client 


inVoker 


RecefVer 


takeOrderO 


setCommancIO 


Sharpen your pencil 


public class GarageDoorOpenCommand implements Command { 
GarageDoor garageDoor; 

public GarageDoorOpenCommand(GarageDoor garageDoor) { 
this.garageDoor = garageDoor; 

} 

public void execute() { 
garageDoor.up(); 

_J_ 

} 


Light is on 
Garage Door is Open 

% 









the command pattern 




We ds for the off button. 

Wr ose here: 


ghtOfi Tiand (light); 

tereoC Command(stereo); 

=nev 

.ottubC Command (hottub); 


Write the undo() method for MacroCommand 


public class MacroCommand implements Command { 
Command[] commands; 

public MacroCommand(Command[] commands) { 
this.commands = commands; 

} 

public void execute() { 

for (int i = 0; i < commands.length; i++) { 
commands[i].execute(); 



public void undo() { 




麗國， D 國 

iBJHiaSB 

a 國 國 

a ! aH HH Hn HH l 

■H HHE HHHEaH HB I 

a 0 

國 Ha 圃 D^HHD 靄 a_?ln.l 
0 


you are here 








Do you think the readers are 
really getting the impression were 
watching a horse race rather than 
sitting in a photo studio? 


In this chapter we’re going to attempt such impossible feats as 
putting a square peg in a round hole. Sound impossible? Not when we have 
Design Patterns. Remember the Decorator Pattern? We wrapped objects to give them new 
responsibilities. Now we’re going to wrap some objects with a different purpose: to make their 
interfaces look like something they’re not. Why would we do that? So we can adapt a design 
expecting one interface to a class that implements a different interface. That’s not all; while 
we’re at it, we’re going to look at another pattern that wraps objects to simplify their interface. 


this is a new chapter 
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Adapters all around us 


You’ll have no trouble understanding what an 00 adapter is 
because the real world is full of them. How’s this for an example: 
Have you ever needed to use a US-made laptop in a European 
country? Then you’ve probably needed an AC power adapter... 



European Wall Outlet 



AC Power Adapter 



Standard AC Plug 





TKc US laptop 



TKc adaptcv dohvcv-ts one 
mtev-fade m-to a^o-tKev. 


You know what the adapter does: it sits in between the plug of your laptop and the 
European AC outlet; its job is to adapt the European outlet so that you can plug your 
laptop into it and receive power. Or look at it this way: the adapter changes the interface 
of the outlet into one that your laptop expects. 

Some AC adapters are simple — they only change the shape of the outlet so that it matches 
your plug, and they pass the AC current straight through - but other adapters are more 
complex internally and may need to step the power up or down to match your devices 5 
needs. 


Okay, that’s the real world, what about object oriented adapters? Well, our OO adapters 
play the same role as their real world counterparts: they take an interface and adapt it to 
one that a client is expecting. 
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Object oriented adapters 

Say you’ve got an existing software system that you need to work a new vendor class library 
into, but the new vendor designed their interfaces differently than the last vendor: 


Your 

Existing 

System 



Vendor 

Class 




Okay, you don’t want to solve the problem by changing your existing code (and you can’t 
change the vendor’s code). So what do you do? Well, you can write a class that adapts the 
new vendor interface into the one you’re expecting. 


Your 

Existing 

System 



The adafiev- implcmch-b -the 
youv classes 


㈣ 二 ^ 


The adapter acts as the middleman by receiving requests from the client and converting 
them into requests that make sense on the vendor classes. 


Your 

Adapter 

Vendor 

Existing 


^ Class 

System 

> 





o r 

从 at 
• I w 、 

vjr 

*to -- w 
Masses? 


抑 w • L 


I -- 


广 

No toAt dKahges 


f 

Kcv/ to&t- 


Ko todt 
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turkey adapter 


If it walks like a duck awd quacks like a duck, 
thew might be a-dWk turkey wrapped 

duck adapter:.. 


with a di 


It’s time to see an adapter in action. Remember our 
ducks from Chapter 1? Let’s review a slightly simpl 
version of the Duck interfaces and classes: 


r & 
ilified 


public interface Duck { 
public void quack(); 
public void fly (); 




Here’s a subclass of Duck, the MallardDuck. 


public class MallardDuck implements Duck { 
public void quack() { 

System, out .println (''Quack ’’）； 

} ^ 

public void fly () { ^ 

System, out .println (''I'm flying"); 

} 




Now ifs time to meet the newest fowl on the block: 


public interface Turkey 
public void gobble(); 
public void fly (); 


丁说邮 




Turkeys tav\ -fly, iKcy 

tav\ only -fly sKovt dis-ta^cs. 
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public class WildTurkey implements Turkey { 
public void gobble() { 

System.out.println (''Gobble gobble ”）； 

} 




public void fly () { 

System, out .print In (''1^ m flying a short distance"); 

} 


Now ， let’s say you’re short on Duck objects and you’d like to 
use some Turkey objects in their place. Obviously we can’t 
use the turkeys outright because they have a different interface. 

So, let’s write an Adapter: 


(We Up Cl^se 


r pivs-t, you need -to 灼七 

o-f -tKc youVc -to. TVis is tKc 

miev-fate youv dieivt -to see. 


public class TurkeyAdapter implements Duck { 

Turkey turkey; 

v\ccd io get a -to 

public TurkeyAdapter (Turkey turkey) { object arc adaft'mj ； 

this • turkey = turkey; wc do iKai iKvoujK to^tW 


} 


public void quack () { 广 ^ Kov/ wc y\tt& to ⑶七 all i\\t methods m 

turkey • gobble () ; i\\t *\ua<^kO iranslatio^ 

} classes is easy ： jus 七乙 dll -t^c jobblcO method- 


public void fly () { 

for (int i=0; i < 5; i++) { 
turkey .fly (); 

} 


£vcr> 七 hou# bo*t^ in-tcv-fa^cs Kavc a -flyO 
method, Tuv-keys -fly m s^ov-t s^uv-is - tKcy 
do lo^j-diis-ta^dc -fly'mj like dutks. To 
…外 brt>wccn a Duck’s -flyO method a^d a 
Turkey’s, >we v\ttd to dall {Mt Turkey’s -flyO 
method -five -times -to make -fov it 
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Test drive the adapter 


Now we just need some code to test drive our adapter: 


public class DuckTestDrive { 

public static void main(String[] args) { 
MallardDuck duck = new MallardDuck() 


, a 


putV.-- 


; C -A 


WildTurkey turkey = new WildTurkey(); 

Duck turkeyAdapter = new TurkeyAdapter(turkey); 

System, out .println (''The Turkey says 
turkey.gobble(); 
turkey .fly (); 

System, out .println (''\nThe Duck says 
testDuck(duck); 


System, out .println (''\nThe TurkeyAdapter says...’’) 
testDuck(turkeyAdapter); 

} 


/W v/va? 
makes i-t look l»kc a Pak. 


TV^, lets -tes-t {he 
make i-t gobble, make i-t 


u\rkcv ： 

t% 


static void testDuck(Duck duck) { 
duck, quack () ; 

} duCk ' flY()； tta °：\ iesi ^ k() ^od;，i 


Movj let’s 七《七七 he dudk 
by taW\y\^ ics-tPudkO 
method, cx.pct'U a 
Pudk object 




、 f^ss 




Test VUh 



I File Edit Window Help Don'tForgetToDuck ■ 


% java RemoteControlTest 
The Turkey says... 

Gobble gobble 

I'm flying a short distance 

The Duck says... 

Quack 
I'm flying 

The TurkeyAdapter says... 
Gobble gobble 
I'm flying a short distance 
I'm flying a short distance 
I'm flying a short distance 
I'm flying a short distance 
I'm flying a short distance 


£ TV Tuv-key gobbles and 
-Plies a short disUftte. 


>^~.TV>e Pwdk <\«*adks and flies 
^ just like youd e 呷 ett. 


,^-s Ar>d ada ? W gobbles 

< auatkO is tailed ar>d ^ a 
Ws is talled ' TV>e 

-tes-tPwdkO method r,evev kr>ov/s , 
has a Wke7 disused as a dutk. 


240 Chapter 7 





the adapter pattern 


The Adapter Pattern explained 

Now that we have an idea of what an Adapter is, let’s step back 
and look at all the pieces again. 




❶ The client makes a request to the 

adapter by calling a method on it using 
the target interface. 

❺ The adapter translates the request into 
one or more calls on the adaptee using 
the adaptee interface. 

❺ The client receives the results of the 
call and never knows there is an adapter 
doing the translation. 


，二 ㈣ ^ 
abo«*t 0 如 ' 
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i ： parpen your pencil 


Let’s say we also need an Adapter that converts a Duck to a Turkey. 
Let’s call it DuckAdapter. Write that class: 


How did you handle the fly method (after all we know ducks fly longer than turkeys)? Check the answers at 
the end of the chapter for our solution. Did you think of a better way? 


tJiereiareno 

Dumb Questipns 


How much “adapting” does 
an adapter need to do? It seems like 
if I need to implement a large target 
interface, I could have a LOT of work on 
my hands. 

You certainly could. The job 
of implementing an adapter really is 
proportional to the size of the interface you 
need to support as your target interface. 
Think about your options, however. You 
could rework all your client-side calls to 
the interface, which would result in a lot 
of investigative work and code changes. 
Or, you can cleanly provide one class that 
encapsulates all the changes in one class. 


Does an adapter always wrap one 
and only one class? 

The Adapter Pattern’s role is to 
convert one interface into another. While 
most examples of the adapter pattern show 
an adapter wrapping one adaptee, we both 
know the world is often a bit more messy. 

So, you may well have situations where an 
adapter holds two or more adaptees that are 
needed to implement the target interface. 

This relates to another pattern called the 
Facade Pattern; people often confuse the 
two. Remind us to revisit this point when we 
talk about facades later in this chapter. 


What if I have old and new parts 
of my system, the old parts expect the 
old vendor interface, but we’ve already 
written the new parts to use the new 
vendor interface? It is going to get 
confusing using an adapter here and the 
unwrapped interface there. Wouldn’t I be 
better off just writing my older code and 
forgetting the adapter? 

Not necessarily. One thing you 
can do is create a Two Way Adapter that 
supports both interfaces. To create a Two 
Way Adapter, just implement both interfaces 
involved, so the adapter can act as an old 
interface or a new interface. 
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Adapter Pattern defined 


Enough ducks, turkeys and AC power adapters; let’s get real and look at the official 
definition of the Adapter Pattern: 


The Adapter Pattern converts the interface of a class 
into another interface the clients expect. Adapter lets 
classes work together that couldn’t otherwise because of 
incompatible interfaces. 


Now, we know this pattern allows us to use a client with an incompatible interface by 
creating an Adapter that does the conversion. This acts to decouple the client from 
the implemented interface, and if we expect the interface to change over time, the 
adapter encapsulates that change so that the client doesn’t have to be modified each 
time it needs to operate against a different interface. 

We’ve taken a look at the runtime behavior of the pattern; let’s take a look at its class 
diagram as well: 



The Adapter Pattern is full of good OO design principles: check out the use of object 
composition to wrap the adaptee with an altered interface. This approach has the 
added advantage that we can use an adapter with any subclass of the adaptee. 

Also check out how the pattern binds the client to an interface, not an 
implementation; we could use several adapters, each converting a different backend 
set of classes. Or, we could add new implementations after the fact, as long as they 
adhere to the Target interface. 
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Object and class adapters 


Now despite having defined the pattern, we haven’t told you the whole story yet. 
There are actually two kinds of adapters: object adapters and class adapters. This 
chapter has covered object adapters and the class diagram on the previous page is a 
diagram of an object adapter. 


So what’s a class adapter and why haven’t we told you about it? Because you need 
multiple inheritance to implement it, which isn’t possible in Java. But, that doesn’t 
mean you might not encounter a need for class adapters down the road when using 
your favorite multiple inheritance language! Let’s look at the class diagram for 
multiple inheritance. 



ar»d Tavy-t classes. 

Look familiar? That’s right — the only difference is that with class adapter we 
subclass the Target and the Adaptee, while with object adapter we use composition 
to pass requests to an Adaptee. 





Object adapters and class adapters use two different means of 
adapting the adaptee (composition versus inheritance). How do these 
implementation differences affect the flexibility of the adapter? 
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Duck Magnets 

Your job is to take the duck and turkey magnets and 
drag them over the part of the diagram that describes 
the role played by that bird, in our earlier example. (Try 
not to flip back through the pages.) Then add your own 
annotations to describe how it works. 


Class Adapter 



Object Adapter 



△ 
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exercise answers 


Duck Magnets 
" Answer 




Class Adapter 


Ped thinks he s 
^ ,kih 9 io a Duck. 


Pwtk dlass 


Twrk ey class 


Client 

► 





request() 





s ㈣ 



丁 二二 t 

- W\f, s 3 ^ c … L •一 £, 3 YX 


I_I 

I he Ad3 ^ le ^e Turkey 代 S(W 

^otZL ：：^ 


补 d W ar t^' 

^ods-^' 


Object Adapter 


Client 


Pud.k *m*tcv-f 3 ^C- 




Client ^hihks he s / 

^ioaD^k. .,, C \assM^' 

I % . T avAtt lS , I \ ^ A\eA 


△ 


㈣ 


ow 


驗 ssss . 

I — - -- 


Adapter 


request() 



specificRequest() 


Tuvkc'/ 

object 


request() specificRequest() 

H e 俨吹， Pi ⑽核丁一巧 A tlaVU ， 

4 士 e 十卜, i£ 衅 _W 4 d ^ a «. 

” ：w 上 “ d Ll^ 0 ^ 

h e ^ls ioaTu , k 
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Fireside Chats 



Tonight’s talk ： The Object Adapter and Class Adapter 
meet face to face. 


Object Adapter 

Because I use composition I’ve got a leg up. I can 
not only adapt an adaptee class，but any of its 
subclasses. 


In my part of the world, we like to use 
composition over inheritance; you may be 
saving a few lines of code，but all I’m doing is 
writing a little code to delegate to the adaptee. 
We like to keep things flexible. 


You’re worried about one little object? You 
might be able to quickly override a method, 
but any behavior I add to my adapter code 
works with my adaptee class and all its 
subclasses. 

Hey, come on，cut me a break, I just need to 
compose with the subclass to make that work. 


Class Adapter 


That’s true, I do have trouble with that because 
I am committed to one specific adaptee class ， 
but I have a huge advantage because I don’t 
have to reimplement my entire adaptee. I can 
also override the behavior of my adaptee if I 
need to because I’m just subclassing. 


Flexible maybe, efficient? No. Using a class 
adapter there is just one of me, not an adapter 
and an adaptee. 


Yeah, but what if a subclass of adaptee adds 
some new behavior. Then what? 


You wanna see messy? Look in the mirror! 


Sounds messy... 
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Real world adapters 

Let’s take a look at the use of a simple Adapter in the real world 
(something more serious than Ducks at least)... 


Old world Enumerators 

If you’ve been around Java for a while 
you probably remember that the early 
collections types (Vector, Stack, Hashtable, 
and a few others) implement a method 
elementsO, which returns an Enumeration. 
The Enumeration interface allows you to 
step through the elements of a collection 
without knowing the specifics of how they 
are managed in the collection. 


c 




at 、。、 


a 




〈〈 interface 〉〉 

Enumeration 


hasMoreElements() 

nextElementQ 



Tells vou there a're ar>7 

elen.er.-b ir, the toliedtior,. 


you the e | er ^七 

the iolled-tioh. 


New world Iterators 

When Sun released their more recent 
Collections classes they began using an 
Iterator interface that, like Enumeration, 
allows you to iterate through a set of items 
in a collection, but also adds the ability to 
remove items. 


«interface> 

Iterator 


>lext() 

0 

^e() 


/WI 05 ⑽七 0 V> 』 ore&efb() 
m -the mle^ate- 

This method jwt tells 70U 
广 Y ouve looked at ail it ⑽ m 


_ you -the 

ih 产外11 邊 > 丄：. 


Removes ah i-tcru 
-Pv-om -the toWttho^. 


And today... 


We are often faced with legacy code that exposes the 
Enumerator interface, yet we’d like for our new code to use 
only Iterators. It looks like we need to build an adapter. 
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Adapting an Enumeration to an Iterator 


First we’ll look at the two interfaces to figure out how the methods map from 
one to the other. In other words ， we’ll figure out what to call on the adaptee 
when the client invokes a method on the target. 


Tavgct mtcv-fadi 




These two rwcthods look easy, 

they map s-tvaight to has/Vc>c-tO 
and ih Itcvatov-. 


«interface» 

Iterator 


«interface» 

Enumeration 

hasNextf) 

next() 

removef) 


hasMoreElements() 

nextElementf) 




Adaptec 


But what about this method 

VCrwovcO m |*tc\ra*to\r? ThevVs 

like that m EhUrwCV-aiioh. 


Pesigning the Adapter 

Here’s what the classes should look like: we need an adapter that implements 
the Target interface and that is composed with an adaptee. The hasNextO and 
next。methods are going to be straightforward to map from target to adaptee: 
we just pass them right through. But what do you do about removeO? Think 
about it for a moment (and we’ll deal with it on the next page). For now, here’s 
the class diagram: 


Youv* Code s-till yts 

-to use l-tcvatovs, CVCh 
i-f -tKcvcs vcally div\ 

6^umCva*tioy> uir\dcvy>ca"t^- 

《 interface 》 

Iterator 

hasNextf) 

next() 

remove() 



Ehumev*a*tio^|*tc\ra*tov 

Enumerationlterator 

is -the adapter. 

hasNext() 

next() 

remove)) 


WcVc "tKc E^umCV-a-tiohS 

•m youv old CoAt look like 
I 七 evatovs -fov* youv 灼 cw Code- 

f\ dass 

^ W\t 

_J «interface» adaytec- 

Enumeration 

hasMoreElements() 

nextElementf) 
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enumeration iterator adapter 

baling with the rewoveO method 

Well, we know Enumeration just doesn’t support remove. It’s a “read only” interface. 
There’s no way to implement a fully functioning remove0 method on the adapter. The 
best we can do is throw a runtime exception. Luckily, the designers of the Iterator 
interface foresaw this need and defined the removeO method so that it supports an 
UnsupportedOperationException. 

This is a case where the adapter isn’t perfect; clients will have to watch out for potential 
exceptions, but as long as the client is careful and the adapter is well documented this is 
a perfectly reasonable solution. 

Writing the Ewuweratiowlterator adapter 

Here’s simple but effective code for all those legacy classes still producing Enumerations: 


public class Enumerationlterator implements Iterator 
{ 

Enumeration enum; 


Smde v/cVc adaft'mj Enumeration 
to Itcv-aW, ouv Adaptev 
implements i\\t l-tcratov m-tcv-fatc... 
••七 has to look like l-tcva-tov. 


public Enumerationlterator(Enumeration 
this.enum = enum; 

} 


匕 The y/cVc adaptmg- 

enum) { usm^ domfositioh so v/C 

i*t m 扣 variable- 


public boolean hasNext() { 

return enum.hasMoreElements(); 


public Object next() { 

return enum.nextElement(); 


tr 



The |*tc\ra*tor s method 

is delegated to the EhUrwevatio^S 
hasMoV-cElcmCh-tsO rwethod... 

… aiY\d the Itcvato^s he 乂 tO method 

is delega 七 ed 七 。 "the Ehurwevatio 灼 s’s 
hCX."t£lcrwCh"tO nr\C*tliod. 


public void remove() { 

throw new UnsupportedOperationException(); 

} 


U^ov-tuy>a-tcly, we tar!i su 代 ov 七 
l-tcra-to^s vcmovcO mc-tiiod, so 
we V>avc -to pu 外七 （m othev v/ovds, 
y/c ^ive upO. tteve wc jus 七七 Wow 

av\ 灼 . 
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While Java has gone in the direction of the Iterator, there is nevertheless a lot of 
legacy client code that depends on the Enumeration interface, so an Adapter 
that converts an Iterator to an Enumeration is also quite useful. 

Write an Adapter that adapts an Iterator to an Enumeration. You can test your 
code by adapting an ArrayList. The ArrayList class supports the Iterator interface 
but doesn’t support Enumerations (well, not yet anyway). 


…- 

Some AC adapters do more than just change the interface — they add other features like surge 
protection, indicator lights and other bells and whistles. 

If you were going to implement these kinds of features, what pattern would you use? 
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Fireside Chats 



Tonight’s talk ： The Decorator Pattern and the Adapter 
Pattern discuss their differences. 


Decorator 


Adapter 


I’m important. My job is all about responsibility - 
you know that when a Decorator is involved there’s 
going to be some new responsibilities or behaviors 
added to your design. 


You guys want all the glory while us adapters 
are down in the trenches doing the dirty work: 
converting interfaces. Our jobs may not be 
glamorous，but our clients sure do appreciate 
us making their lives simpler. 


That may be true, but don’t think we don’t 
work hard. When we have to decorate a big 
interface, whoa, that can take a lot of code. 


Cute. Don’t think we get all the glory; sometimes 
I’m just one decorator that is being wrapped by 
who knows how many other decorators. When a 
method call gets delegated to you, you have no 
idea how many other decorators have already dealt 
with it and you don’t know that you’ll ever get 
noticed for your efforts servicing the request. 


Try being an adapter when you’ve got to bring 
several classes together to provide the interface 
your client is expecting. Now that’s tough. But 
we have a saying: “an uncoupled client is a 
happy client.’’ 


Hey, if adapters are doing their job, our clients 
never even know we’re there. It can be a thank¬ 
less job. 
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Decorator Adapter 

But, the great thing about us adapters is that we 
allow clients to make use of new libraries and 
subsets without changing any code, they just rely 
on us to do the conversion for them. Hey, it’s a 
niche, but we’re good at it. 

Well us decorators do that as well, only we allow 
new behavior to be added to classes without altering 
existing code. I still say that adapters are just fancy 
decorators - 1 mean, just like us, you wrap an object. 

No, no, no, not at all. We always convert the 
interface of what we wrap, you never do. I’d 
say a decorator is like an adapter; it is just that 
you don’t change the interface! 

Uh, no. Our job in life is to extend the 
behaviors or responsibilities of the objects we 
wrap, we aren’t a simple pass through. 

Hey, who are you calling a simple pass 
through? Come on down and we’ll see how 
\ongyou last converting a few interfaces! 

Maybe we should agree to disagree. We seem 
to look somewhat similar on paper, but clearly 
we are miles apart in our intent. 

Oh yeah, I’m with you there. 


you are here ► 253 



who does what? 


And wow for something different... 

There’s another pattern in this chapter. 

You’ve seen how the Adapter Pattern converts the interface of a class into 
one that a client is expecting. You also know we achieve this in Java by 
wrapping the object that has an incompatible interface with an object that 
implements the correct one. 

We’re going to look at a pattern now that alters an interface, but for a 
different reason: to simplify the interface. It’s aptly named the Facade 
Pattern because this pattern hides all the complexity of one or more 
classes behind a clean, well-lit facade. 




C^nVerts pne Interface io 

DecorsitPr 

anptlier 

Adapter 

Dpesn ? t cJter ihe Interface, but 
adds resppnslkllit/ 

Facade 

M^lkes an Interface simpler 
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Home Sweet Home theater 


Before we dive into the details of the Facade Pattern, let’s take a look 
at a growing national obsession: building your own home theater. 

You’ve done your research and you’ve assembled a killer system 
complete with a DVD player, a projection video system, an 
automated screen, surround sound and even a popcorn popper. 

Check out all the components you’ve put together: 





That’s a lo 七 of 
classes, a lot 


of m-bcv-a^-bio^s, 

av\d a bi^ set o-f 

m-tcv-fa^cs -bo 


\cary\ av\d use 


You’ve spent weeks running wire, mounting the projector, making all 
the connections and fine tuning. Now it’s time to put it all in motion 
and enjoy a movie... 
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tasks to watch a movie 


Watching a movie (the hard way) 

Pick out a DVD, relax, and get ready for movie magic. Oh, 
there’s just one thing - to watch the movie, you need to 
perform a few tasks: 

O Turn ow the popcorn popper 
O Start the popper popping 
❺ Piw the lights 
O Put the screen down 
❺ Turn the projector ow 
O Set the projector input to I?YP 
Q Put the projector ow wide-screew mode 
O Turn the sound amplifier on 
O Set the amplifier to PYP input 
® Set the amplifier to surround sound 
© Set the amplifier volume to medium (5) 
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Let’s check out those same tasks in terms of the classes and the 
method calls needed to perform them: 


Masses 




oWcd! 




popper•on (); 
popper.pop (); 

lights.dim(10); 

screen.down(); 


Twvr> or. the \>o\>dovir. ?o\>\>ev and stavt 


P*»m i\\t -to 10 %… 




pu 七七 Sdvccr^ dovm … 


projector.on (); 

projector.setlnput(dvd); 

projector.wideScreenMode() 


* T«*vn or> tKe ^rojed-U- a«d \>«*t *-t 
wide sdveer> mode ^ov the movie... 


amp.on(); 

amp.setDvd(dvd); 

amp.setSurroundSound(); 

amp.setVolume(5); 



dvd.on(); 

dvd.play(movie); 



Tuv-r. or. the am\>, set \i ^ 

\i m swv-v-ound sound mode ar>d set the 


volume "to … 


Tuv-r, o*> the P\/P \>bYPr … 

一 PINAL-LV， ? lav the movie! 


But there’s more... 

■ When the movie is over, how do you turn everything off? 
Wouldn’t you have to do all of this over again, in reverse? 

■ Wouldn’t it be as complex to listen to a CD or the radio? 

■ If you decide to upgrade your system, you’re probably going 
to have to learn a slightly different procedure. 


So what to do? The complexity of using your home theater is becoming apparent! 

Let’s see how the Facade Pattern can get us out of this mess so we can enjoy the movie... 
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lights camera facade 

Lights, Camera, Facade! 


A Facade is just what you need: with the Facade Pattern you can take a complex 
subsystem and make it easier to use by implementing a Facade class that 
provides one, more reasonable interface. Don’t worry; if you need the power 
of the complex subsystem, it’s still there for you to use, but if all you need is a 
straightforward interface, the Facade is there for you. 

Let’s take a look at how the Facade operates: 


A Okay, time to create a 
V Facade for the home 
theater system. To do 
this we create a new class 

Home 丁 heaterFacade, 

which exposes a few 
simple methods such as 
watchMovieO. 


TV»e fatade 


HomeTheaterFacade 

watchMovie() 

endMovie() 

listenToCd() 

endCd() 

listenToRadio() 

endRadio() 


©The Facade class treats 
the home theater 
components as a 
subsystem, and calls 
on the subsystem 
to implement its 
watchMovieQ method. 
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Your client code now calls 
methods on the home theater 

Facade, not on the subsystem. 

So now to watch a movie we just 
call one method, watchMovieO, 
and it communicates with the 
lights, DVD player, projector, 

amplifier, screen, and popcorn 

maker for us. 


A o( the 
subsystem ^fa^ade 


I’ve got to have my 
low-level access! 


■\\j oycsulc^ ok 
sWore ^ ^ool 

/M t 


Q The Facade still leaves the subsystem 
accessible to be used directly. If you 
need the advanced functionality 
of the subsystem classes, they are 
available for your use. 


facade versus adapter 


tfcere are np 

Dumb Questipns 


If the Facade encapsulates the 
subsystem classes, how does a client 
that needs lower-level functionality gain 
access to them? 

Facades don’t “encapsulate” the 
subsystem classes; they merely provide a 
simplified interface to their functionality. The 
subsystem classes still remain available 
for direct use by clients that need to use 
more specific interfaces. This is a nice 
property of the Facade Pattern: it provides 
a simplified interface while still exposing the 
full functionality of the system to those who 
may need it. 


What is the benefit of the facade 
other than the fact that I now have a 
simpler interface? 

The Facade Pattern also allows 
you to decouple your client implementation 
from any one subsystem. Let’s say for 
instance that you get a big raise and decide 
to upgrade your home theater to all new 
components that have different interfaces. 
Well, if you coded your client to the facade 
rather than the subsystem, your client code 
doesn’t need to change, just the facade 
(and hopefully the manufacturer is supplying 
that!). 


Does the facade add any 
functionality or does it just pass through 
each request to the subsystem? 

A facade is free to add its own 
“smarts” in addition to making use of the 
subsystem. For instance, while our home 
theater facade doesn’t implement any new 
behavior, it is smart enough to know that the 
popcorn popper has to be turned on before it 
can pop (as well as the details of how to turn 
on and stage a movie showing). 




Does each subsystem have only 


one facade? 


Not necessarily. The pattern 
certainly allows for any number of facades to 
be created for a given subsystem. 


So the way to tell the difference 
between the Adapter Pattern and the 
Facade Pattern is that the adapter wraps 
one class and the facade may represent 
many classes? 

No! Remember, the Adapter Pattern 
changes the interface of one or more 
classes into one interface that a client is 
expecting. While most textbook examples 
show the adapter adapting one class, you 
may need to adapt many classes to provide 
the interface a client is coded to. Likewise, 
a Facade may provide a simplified interface 
to a single class with a very complex 
interface. 

The difference between the two is not in 
terms of how many classes they “wrap,” it 
is in their intent. The intent of the Adapter 
Pattern is to alter an interface so that it 
matches one a client is expecting. The 
intent of the Facade Pattern is to provide a 
simplified interface to a subsystem. 


A iacacte not 
only simplifies 
an interface, it 
ctecouples a client 
: from a sutsystem 
components. 

Facactes anct 
adapters may 
wrap multiple 
classes, Lut a 
: tacacte’s intent is 
to simplify, wkile 
an adapters 
is to convert 
tke interface 
to sometking 
ctiHerent. 
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Cowstructiwg your home theater facade 

Let’s step through the construction of the HomeTheaterFacade : The 
first step is to use composition so that the facade has access to all the 
components of the subsystem: 


public class HomeTheaterFacade { , 

Amplifier amp; Wtrts dom\>os*it'io^ these 

Tuner tuner; 广 ""— ^ avc 3ll o-r 

DvdPlayer dvd; suksvs*tcm wc av-c io use- 

CdPlayer cd; 

Projector projector; 

TheaterLights lights; 

Screen screen; 

PopcornPopper popper; 


public HomeTheaterFacade (Amplifier amp, 


Tuner tuner, 

DvdPlayer dvd, 
CdPlayer cd. 

Projector projector. 
Screen screen, 
TheaterLights lights, 
PopcornPopper popper) 

this.amp = amp; 
this.tuner = tuner; 
this.dvd = dvd; 
this.cd = cd; 

this.projector = projector; 
this.screen = screen; 


The ^adadc is passed a 

io tac\) do 你七 

Jc subs'ys'tcm m 如 
doy>s-tvu6-tov. The -fadadc 
assies cath io -tKc 
dovvcspoWn^ vaviablc- 


this.lights = lights; 
this.popper = popper; 


// other methods here 



^V e jusi a bo ， i£ 0 ^|, £ hese i. 
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Implementing the simplified interface 

Now it’s time to bring the components of the subsystem together into a unified interface. 
Let’s implement the watchMovieQ and endMovieQ methods: 


public void watchMovie(String movie) 
System, out .println (''Get ready to 
popper.on(); 
popper.pop(); 
lights.dim(10); 
screen.down(); 
proj ector.on(); 
projector.wideScreenMode(); 
amp.on(); 
amp.setDvd(dvd); 
amp.setSurroundSound(); 
amp.setVolume(5); 
dvd.on(); 
dvd.play(movie); 


{ 

watch a movie. 


.aWovieO ^oiUs 肀 

v, e had to do by V>ar>d W 卜十七 
\i iap rn a V^a^Y me 七 W 七 al 

tovves — 吋 t 呼怵 Ue subsYster, 


public void endMovie() { 

System, out .println (''Shutting movie theater down . . . ,r ); 
popper.off (); 


lights.on(); 
screen.up(); 
projector.off() 
amp.off(); 
dvd.stop(); 
dvd.eject(); 
dvd.off(); 




TWd c^d/VIovicO -takes tavc 
s huttmg cvciry-th'mg dowr> 
iov us. Aga'm, -task is 
delegated -to the appropriate 
^orwpohCht ih the subsystem. 




Think about the facades you’ve encountered in the Java API. 
Where would you like to have a few new ones? 
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Time to watch a movie (the easy way) 

It，s SHOWTIME! 



public class HomeTheaterTestDrive { 

public static void main(String[] args) 
// instantiate components here 

HomeTheaterFacade homeTheater = 

new HomeTheaterFacade(amp, 
projector, screen. 



vi^-b m -b^c test divivc- Nov-mally 
d\cv\i is a -facade, it dotsr!i V>avc 
*to do^S"tv*ud"t or\C 


tuner, dvd, cd, 
lights, popper); 


homeTheater. watchMovie (''Raiders 
homeTheater.endMovie(); 


of the Lost Ark 〃）； 


piv-s-t you 

i\\t Facade wi-bK all i\\t 

m 七 he subsys-bc^- 


pse the simpli-fied \y\icr(atc io 
s-ta\rt the movie up, 
theh shut it dovm. 


Hcv-c ； s the output. 

Callihg the facades 
watdh/VIovicO does all 

this wovk (or us... 



...ahd here, wcVc doY\t 
wa-tdhihj the movie, so 
乙 allihg ChdA/JovicO -tuv-h 
cvcirythmg o^f. 、 




I File Edit Window Help SnakesWhy'dItHaveToBeSnakes? ■ 


% java HomeTheaterTestDrive 

Get ready to watch a movie... 

Popcorn Popper on 

Popcorn Popper popping popcorn! 

Theater Ceiling Lights dimming to 10% 

Theater Screen going down 
Top-O—Line Projector on 

Top-O-Line Projector in widescreen mode (16x9 aspect ratio) 
Top-O-Line Amplifier on 

Top-O-Line Amplifier setting DVD player to Top-O-Line DVD Player 
Top-O-Line Amplifier surround sound on (5 speakers, 1 subwoofer) 
Top-O-Line Amplifier setting volume to 5 
Top-O-Line DVD Player on 

Top-O-Line DVD Player playing ''Raiders of the Lost Ark 〃 

Shutting movie theater down... 

Popcorn Popper off 
Theater Ceiling Lights on 
Theater Screen going up 
Top-O-Line Projector off 
Top-O-Line Amplifier off 

Top-O-Line DVD Player stopped ''Raiders of the Lost Ark" 
Top-O-Line DVD Player eject 
Top-O-Line DVD Player off 

% 
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Facade Pattern defined 


To use the Facade Pattern, we create a class that simplifies and unifies a set of more 
complex classes that belong to some subsystem. Unlike a lot of patterns, Facade is fairly 
straightforward; there are no mind bending abstractions to get your head around. But that 
doesn’t make it any less powerful: the Facade Pattern allows us to avoid tight coupling between 
clients and subsystems, and, as you will see shortly, also helps us adhere to a new object 
oriented principle. 

Before we introduce that new principle, let’s take a look at the official definition of the pattern: 


The Facade Pattern provides a unified interface to a 
set of interfaces in a subsytem. Facade defines a higher- 
level interface that makes the subsystem easier to use. 


There isn’t a lot here that you don’t already know, but one of the most important things 
to remember about a pattern is its intent. This definition tells us loud and clear that the 
purpose of the facade it to make a subsystem easier to use through a simplified interface. 
You can see this in the pattern’s class diagram: 



That’s it; you’ve got another pattern under your belt! Now, it’s time for that new OO principle. 
Watch out, this one can challenge some assumptions! 
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The Principle of Least Knowledge 

The Principle of Least Knowledge guides us to reduce the 
interactions between objects to just a few close “friends.” 
The principle is usually stated as: 



But what does this mean in real terms? It means when you 
are designing a system, for any object, be careful of the 
number of classes it interacts with and also how it comes to 
interact with those classes. 

This principle prevents us from creating designs that have 
a large number of classes coupled together so that changes 
in one part of the system cascade to other parts. When you 
build a lot of dependencies between many classes, you are 
building a fragile system that will be costly to maintain and 
complex for others to understand. 


溢抑 A … - 

How many classes is this code coupled to? 

public float getTemp () { 

return station.getThermometer () .getTemperature (); 
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principle of least knowledge 


How NOT to Wiw Friends a^d Influence Objects 


Okay, but how do you keep from doing this? The principle 
provides some guidelines: take any object; now from any 
method in that object, the principle tells us that we should 
only invoke methods that belong to: 

■ The object itself 

■ Objects passed in as a parameter to the method 

■ Any object the method creates or instantiates 

■ Any components of the object 


- TW,k 


This sounds kind of stringent doesn’t it? What’s the harm in 
calling the method of an object we get back from another 
call? Well, if we were to do that, then we’d be making a 
request of another object’s subpart (and increasing the 
number of objects we directly know). In such cases, the 
principle forces us to ask the object to make the request for us; 
that way we don’t have to know about its component objects 
(and we keep our circle of friends small). For example: 




public float getTemp () { 

Thermometer thermometer = station.getThermometer(); 
return thermometer.getTemperature(); 

} 

Hcv-c yk -t^cvmomc-tcv- object 

•fvom s-tatior\ ar\d 从⑺ tall 七^ 

gctTCrv»^CVa't'AV-cO method ouvsclvcs. 



WvtVj i\\t 
Pvm 6 \>lc 


public float getTemp () { 

return station.getTemperature(); 

} 




v/e v/c add a 

mc-t^odi io i\>t S-btion dass i\\ai *^akcs 
七 ^ vc<\ucs 七七。 七 ^ -fov us. 

This v-cdudcs i\^t o-f classes y/cVc 


on. 
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Keeping your method calls m bounds... 


Here’s a Car class that demonstrates all the ways you can call methods and still 
adhere to the Principle of Least Knowledge: 


public class Car { 

Engine engine; 

// other instance variables 

public Car() { 

// initialize engine, etc. 

} 


-,-ts nv 办 ods. 


public void start(Key key) { 

Doors doors = new Doors(); 



ttcv-c y/cVc tvcai'mj a 
objcd-ti i"U methods avc legal- 

You tar\ 匕 all a method 
or\ an objedt passed as 
a \>avar«c-tc\r. 


boolean authorized 
if (authorized) { 


|key. turns () j] 


engine.start(); 


updateDashboardDisplay();| 


doors.lock();[ 


} 


public void updateDashboardDisplay() 
// update display 

} 


you 63 ^ 


tall a method a 
: 釓 d ^ 0 吵乇 . 


、 You tar\ dall a lodal method 
object 

Y^ou dah dall a mc-tKod oy\ 
objed-t you dirca-tc ov- ihs-tarv-tia-tc. 


There is another principle called 
the Law of Demeter; how are they 
related? 

The two are one and the same 
and you’ll encounter these terms being 
intermixed. We prefer to use the Principle of 
Least Knowledge for a couple of reasons: (1) 
the name is more intuitive and (2) the use of 
the word “Law” implies we always have to 


DumPc^uestipns 

apply this principle. In fact, no principle is a 
law, all principles should be used when and 
where they are helpful. All design involves 
tradeoffs (abstractions versus speed, space 
versus time, and so on) and while principles 
provide guidance, all factors should be taken 
into account before applying them. 

Are there any disadvantages 
to applying the Principle of Least 
Knowledge? 


Yes; while the principle reduces 
the dependencies between objects and 
studies have shown this reduces software 
maintenance, it is also the case that 
applying this principle results in more 
“wrapper” classes being written to handle 
method calls to other components. This 
can result in increased complexity and 
development time as well as decreased 
runtime performance. 
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violating the principle of least knowledge 


f Sharpen your pencil 


Do either of these classes violate the Principle of Least Knowledge? 
Why or why not? 


public House { 

Weatherstation station; 

// other methods and constructor 


public float getTemp () { 

return station.getThermometer().getTemperature(); 


public House { 

Weatherstation station; 

// other methods and constructor 

public float getTemp () { 

Thermometer thermometer = station.getThermometer(); 
return getTempHelper(thermometer); 


public float getTempHelper(Thermometer thermometer) 
return thermometer.getTemperature(); 



HARD HAT AREA. WATCH OUT 
FOR FALLING ASSUMPTIONS 


Can you think of a common use of Java that violates the Principle of Least Knowledge? 
Should you care? 
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The Facade and the Principle of Least Knowledge 


the adapter pattern 
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your design toolbox 


TT 


Tools for your design Toolbox 


Your toolbox is starting to get heavy! In this 
chapter we’ve added a couple of patterns that 
allow us to alter interfaces and reduce coupling 
between clients and the systems they use. 




QO ?v'w^ cS \ 

一一 : ：二 ，' 

.♦ 身 - I 

㈣ 二 
r 二二 A 


tetVv^ I 
^ w，a， '?. :: 。吖 如妒 . 


...w Tm _ ?atw. 

^drvjcs ar» nrrbcv<dtc, 

i\\t adafbev ■ 七 。 donvcvt 
and fatade to ^'»<V 

dr\d s'im\>l'i-fY 

/ I 


L. l^C mtcv^ tc 


o^uCS*t 


J 


,C. c d 


BULLET POINTS 


■ When you need to use an 
existing class and its interface 
is not the one you need, use an 
adapter. 

■ When you need to simplify 
and unify a large interface or 
complex set of interfaces, use a 
facade. 

■ An adapter changes an 
interface into one a client 
expects. 

■ A facade decouples a client 
from a complex subsystem. 

■ Implementing an adapter may 
require little work or a great deal 
of work depending on the size 
and complexity of the target 
interface. 

■ Implementing a facade requires 
that we compose the facade 
with its subsystem and use 
delegation to perform the work 
of the facade. 

■ There are two forms of the 
Adapter Pattern: object and 
class adapters. Class adapters 
require multiple inheritance. 

■ You can implement more than 
one facade for a subsystem. 

■ An adapter wraps an object to 
change its interface, a decorator 
wraps an object to add new 
behaviors and responsibilities, 
and a facade “wraps” a set of 
objects to simplify. 


270 Chapter 7 



the adapter pattern 



Yes, it’s another crossword. All of the solution words are from this chapter. 



Across 

I. True or false, Adapters can only wrap one 
object 

5. An Adapter_an interface 

6. Movie we watched (5 words) 

10. If in Europe you might need one of these 
(two words) 

II. Adapter with two roles (two words) 

14. Facade still_low level access 

15. Ducks do it better than Turkeys 

16. Disadvantage of the Principle of Least 

Knowledge: too many_ 

17. A_simplifies an interface 

19. New American dream (two words) 


Down 

2. Decorator called Adapter this (3 words) 

3. One advantage of Facade 

4. Principle that wasn't as easy as it sounded 
(two words) 

7. A_adds new behavior 

8. Masquerading as a Duck 

9. Example that violates the Principle of Least 

Knowledge: System.out._ 

12. No movie is complete without this 

13. Adapter client uses the_interface 

18. An Adapter and a Decorator can be said to 
_an object 
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exercise solutions 



Exercise 

solutions 


Parpen your pencil 


Let’s say we also need an adapter that converts a Du 
Let’s call it DuckAdapter. Write that class: 



r 二， 

TuyVe'f 




public class DuckAdapter implements Turkey { 
Duck duck; 

Random rand; 


public DuckAdapter (Duck duck.) { 
this.duck = duck; 
rand = new Random(); 

} 


1/Ve siash a vc-fcvcufie to 


public void gobble() 
duck.quack(); 

} 


also ⑽…七亡 a fandom objed-t; 
■take a look a 七 "the -flyO »e-tKod 
{jo see Kow i-t is used- 


public void fly () { 

if (rand.nextlnt(5) 
duck. fly (); 

} 

} 


/\ gobble jws 七 be£o*«cs d <\uadk- 




卽 


dwdk or> avcvay c 


「pen your pencil 


Do either of these classes violate the Principle of Least Knowledge? 
For each, why or why not? 


public House { 

Weatherstation station； 


// other methods and constructor 


public float getTemp () { 

return station.getThermometer().getTemperature(); 
} - - -- _ _ 


public House { 

Weatherstation station； 


// other methods and constructor 




、 X Least ^ e ^ e! 


public float getTemp () { 

Thermometer thermometer = station.getThermometer()； 
return getTempHelper(thermometer); 

} 

public float getTempHelper (Thermometer thermometer) { 
return thermometer.getTemperature(); 

办 P™6 f l^ua s t 冗抑 I 


jws-t C 


s'wte xe 
， e-tV»odi? 
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the adapter pattern 


Exercise solutions 


You’ve seen how to implement an adapter that adapts an Enumeration to an 
Iterator; now write an adapter that adapts an Iterator to an Enumaration. 


public class IteratorEnumeration implements Enumeration { 
Iterator iterator; 

public IteratorEnumeration(Iterator iterator) { 
this.iterator = iterator; 


public boolean hasMoreElements() { 
return iterator.hasNext(); 


public Object nextElement() { 

return iterator.next(); 


- O 备瞽孓 - 

m 

Match each pattern with its intent: 

Pattern Intent_ 

ConVert Pne Interface fo 
onotlier 

Don't alter Interface, but add 
responsibility 


jVfake Interface simpler 
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Exercise solutions 
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8 the Template M^th^d 

.Encapsulating + ^ 
♦ Algorithms ^ 



We’re on an encapsulation roll; we’ve encapsulated object 
creation, method invocation, complex interfaces, ducks, 
pizzas... what could be next? We’re going to get down to encapsulating 
pieces of algorithms so that subclasses can hook themselves right into a computation 
anytime they want. We’re even going to learn about a design principle inspired by 
Hollywood. 


this is a new chapter 
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coffee and tea recipes are similar 


Ifs time for some more caffeine 

Some people can’t live without their coffee; some 
people can’t live without their tea. The common 
ingredient? Caffeine of course! 

But there’s more; tea and coffee are made in very 
similar ways. Let’s check it out: 


c 秦一 “ 一 〆 

S 愼 W C ° 你 e reciP eS 

,pxease 糾二二⑽ • 

工 S 产 n Preparl 
⑴ BOil S e £ ee a t" r ^ iUng 

( 2 ) Bre« cot ^ ^ 

二二 ra 一 

w s r a 二 … ater 

% s :: ^ cup 
(( 4) Add lemorv 

讲 ㈣ + 




TV^c rtt^t ^ov 
to-f-fcc looks a lot 
|\kc rt^t ^ov 
■tea, dowt >t? 
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Whipping up some coffee and tea classes 
(in Java) 

Let’s play “coding barista” and write 
some code for creating coffee and tea. 

Here’s the coffee: 





public class Coffee { 


void prepareRecipe() { 
boilWater(); 
brewCoffeeGrinds(); 
pourInCup(); 
addSugarAndMilk(); 




5 uw 抑 .— ? wntedas 

-L- — 


public void boilWater() { 

System, out .printIn (''Boiling water"); 


public void brewCoffeeGrinds() { 

System, out .print In (''Dripping Coffee through filter"); 


public void pourlnCup() { 

System, out .printIn (''Pouring into cup 〃）； 



public void addSugarAndMilk() { 

System, out .println (''Adding Sugar and Milk"); 



o( ttese methods 
orve stcip o-f 

七 algov'rtV^m. TV^cvc s 
a method to bo»l v/aW ， 
bvcv/ tV^c to((cc, ?ouv 
i\\t toWcc and 

add su^av 州 “k. 
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tea implementation 


and now the Tea... 


public class Tea 


void prepareRecipe() 
boilWater(); 
steepTeaBag(); i 
pourlnCup(); 
addLemon(); 

} 


丁 his looks vcvy similav "to tKc 
y/c just m 

Co-f-fcc ； -tKc second ar>d -fov-tK 
steps avc bui it’s 

basidally iKc same 



public void boilWater() { 

System, out .println (''Boiling water"); 

} 



t'/otitc 七 


public void steepTeaBag() { 

System, out .println (''Steeping the 


tea"), 


TV^csc 七叫。 


} 

public void addLemon() { 

System, out .println (''Adding Lemon"); 

} 



methods 3V*C 

s\>cd.»al>zjcd to 

Tea- 


methods 3V*C 

cx-attiY 

same as ^ 
m CoUcc! So 
Vie dc-f mitclY 

V^ave some Code 


public void pourlnCup() { 

System, out .println (''Pouring into cup ”）； 

} 


du\>l'» 6 at>or\ 



\\Crt- 
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Design Puzzle 


You’ve seen that the Coffee and Tea classes have a fair bit of code duplication. Take 
another look at the Coffee and Tea classes and draw a class diagram showing how you’d 
redesign the classes to remove redundancy: 
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first cut at abstraction 


Sir ： may I abstract your Coffee, Tea? 

It looks like we’ve got a pretty straightforward design 
exercise on our hands with the Coffee and Tea classes. 

Your first cut might have looked something like this: 


CaffeineBeverage 


t =i) 二 ;^ r 

so -tv>e7 ave deWli rn ^ w 6 


T^ e? a^R et ; ?e () 

i„ ea(1 h subclass, so \t is 
de+ihed as absi^d 


prepareRecipe() 

boilWater() 

pourlnCupQ 



subclass 

iis 

ovm 


Coffee 


Tea 

prepareRecipe() 


prepareRecipe() 

brewCoffeeGrinds() 


steepTeaBag() 

addSugarAndMilk() 


addLemon() 


Ea^K subdlass overrides 
iKc ^vc^av-cRcti\>cO 
mctKod and 
i-ts own retire- 



Tk 


me ^ods s ? et ； 


and Tea » 


Co«« 

\y, t sub^asscs. 


Did we do a good job on the redesign? Hmmmm, take another look. Are we overlooking some other 
commonality? What are other ways that Coffee and Tea are similar? 
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Taking the design further:.. 


So what else do Coffee and Tea have in common? Let’s start with 
the recipes. 



Notice that both recipes follow the same algorithm: 

^ - - ^ 

O Poil some water 

❾ Usethehotwatertoextractthecoffee 

OK tea. avc "tV^c same, 七 V\e base Mass. 

O Pour the resulting beverage mtoa cup. 

O Add the appropriate condiments to the 
beverage. 



So, can we find a way to abstract prepareRecipe() too? Yes, let’s find out... 
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abstract the algorithm 


Abstracting prepareRecipeO 


Let’s step through abstracting prepareRecipe() 
from each subclass (that is，the Coffee and Tea 
classes)... 

The first problem we have is that Coffee uses brewCofTeeGrindsO and 
addSugarAndMilkO methods while Tea uses steepTeaBagO and addLemonO 
methods. 


Coffee 


Tea 


void prepareRecipe() { 


void prepareRecipe() 

boilWater(); 



boilWater (); 

brewCoffeeGrinds() ; ^ - 

- ~~\ — 

— > 

steepTeaBagO; 

pourlnCup(); 

V 


pourlnCup (); 

addSugarAndMilk(); ^ - 

} 

V. 

- > 

} 

addLemon(); 


Let’s think through this: steeping and brewing aren’t so different; they’re pretty analogous. 
So let’s make a new method name, say ， brew()，and we’ll use the same name whether 
we’re brewing coffee or steeping tea. 

Likewise, adding sugar and milk is pretty much the same as adding a lemon: both 
are adding condiments to the beverage. Let’s also make up a new method name, 
addCondimentsO, to handle this. So, our new prepareRecipeQ method will look like this: 


void prepareRecipe() { 
boilWater(); 
brew (); 
pourlnCup (); 
addCondiments(); 


Now we have a new prepareRecipeQ method, but we need to fit it into the code 
To do this we are going to start with the CaffeineBeverage superclass: 
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c a « e 』 e v e — ab 似 七 ，〆 
like m tlass des ， 

public abstract class CaffeineBeverage { 

final void prepareRecipe () { 

boilWater(); 
brew(); 
pourlnCup(); 
addCondiments(); 


abstract void brew(); 




abstract void addCondiments(); 


t 。 be —” 

We've waWd ^ ^ ^ 

如 b e v 崎 a«dl iAACcr,d\^Hl 


Betawe CMee a»d Tea handle lV>ese "»elV>ods 
m di-f-feven-t ways, lV>eyVe jo'nnj io V>ave io 
be detlaved as abs-tvati Lei tV>e subtlasses 
v/oV'V'Y dbou*t 七七 s 七 1 


void boilWater() { 

System, out .printIn (''Boiling water"); 

} 

void pourlnCup() { 

System, out .printIn (''Pouring into cup"); 

} 


Rcmcmbcv, y/C moved -tKcsc iivto 
iKc Ca-f-fcincBcvcvajc dlass (badk 
•m ouv- dass diagv-am). 


Finally we need to deal with the Coffee and Tea classes. They now rely on 
CafTeineBeverage to handle the recipe, so they just need to handle brewing and 
condiments: 


public class Tea extends CaffeineBeverage { 
public void brew() { 

System, out .println (''Steeping the tea 〃）； 

} 

public void addCondiments() { 

System, out .println (''Adding Lemon"); 

} 


m ouv* desi ， 丁 ea and 


Y\O^I 作七伙 d 1 


jcvcvajc- 




4r 




public class Coffee extends CaffeineBeverage 
public void brew() { 

System, out .println (''Dripping Coffee through filter"); 

} 

public void addCondiments() { 

System. out.println (''Adding Sugar and Milk :〃） ； 

} 


Tc3 Y\ttds "to dc-fmc bvcy/O and 

addCcmdUcrAsO — 衽 C "Uo a\>sirati 
methods -fv-ow Bcvcv-ajc- 

Same -fov CoWcc, Cof-fcc deals 

y/i-tV) toffee, and sugav and r»*ilk ms-tcad 
o*f -tea bags and lew。”. 
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class diagram for caffeine beverages 


! Sharpen your pencil 


Draw the new class diagram now that we’ve moved the 
implementation of prepareRecipe() into the CaffeineBeverage class: 
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What have we dowe? 


the template method pattern 


❹ ?oil some water 

❾ sw—— 

❺ pourtealwacup 


vcdoghiz^d 
"tKa-t the two vcdipcs 
av-c essentially the 
same, although 

some o( -the steps 
vc<\uiv-c di-f-fcvchi 
irwplcmch-ta-tiohs. So 
v/c^e jchcvaliz^d the 
vedipe and flawed it m 
■the base dlass. 



❹ M_(m 



c off ee 

❶ 如 1 m ewater 


0 : 

° Add 如财， k 



Caffeine leverage 

O Poil sowe water 


O ⑽ w 



❾ Steep the teabag in the water 


O Pour beverage in a cup 
❹ Add condiwe^its 



O Add lemon 


velies on uaor . 

i ^ do sW s 2 - and 





❾ ^rew 1 ：^« coffee grinds 

❹ ^dd sugar a»»d milk 
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meet the template method pattern 


Meet the Template Method 

We’ve basically just implemented the Template Method Pattern. What’s that? Let’s look 
at the structure of the CaffeineBeverage class; it contains the actual “template method:” 


public abstract class CaffeineB { 


void final prepareRecipe () { 


boilWater(); 


brew (); 


pourlnCup(>; 


addCondiments(); 



abstract void brew(); 

abstract void addCondiments(); 

void boilWater() { 

// implementation 

} 

void pourlnCup() { 

// implementation 

} 



.is ouv -tcnr»\>laic method 

iA/v>y? 

Because ： 

(I) |七 is a nr»ctV>od, all- 

(2J I 七 serves as a icwflatc or an 
aly^ritw, m dasc, an algon-tv^^ (or 
making da-f-fc'ma-tcd bevevajes. 

h ttc template, cadh s-tep o( 
is V-cpvcsch-tcd 

by a method. 

Some methods avc Kahdled 
by this dlass... 

… ahd some arc Kahdled 
by -the subdldss. 

The methods -that heed 七。 
be supplied by a subdlass are 
dedared abs-tv-adt 


Tlie Template Metkod cteiines tke steps oi an algforitlim anct allows 
subclasses to provicte tke implementation : for one or more steps. 


286 Chapter 8 




the template method pattern 


Let's make some tea... 


Let’s step through making a tea and trace through 
how the template method works. You’ll see that 
the template method controls the algorithm; at 
certain points in the algorithm, it lets the subclass 
supply the implementation of the steps... 


Beldnd / 麵 

die Scenes^*^ 


Okay, first we need a Tea object... 

Tea myTea = new Tea(); 


boilWater(); 
brew(); 
pourlnCup(); 
addCondiments(); 


] 


❾ 


o 


Then we call the template method: 

myTea.prepareRecipe(); 

which follows the algorithm for making caffeine 
beverages... 

First we boil water: 


TKc pvcfdv-cRcdifcO 
dor\-tvols 

*tV\is, ar\d 

dounis or\ subclasses to 
^vovidc sowc or dll 
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what did template method get us? 


What did the Template Method get us? 



Underpowered TeaS- Coffee 
implementation 



New, hip CaffeiwePeverage 
powered by Template Method 


Coffee and Tea are running the show; 
they control the algorithm. 


Code is duplicated across Coffee and 
Tea. 


Code changes to the algorithm 
require opening the subclasses and 
making multiple changes. 

Classes are organized in a structure 
that requires a lot of work to add a 
new caffeine beverage. 


Knowledge of the algorithm and how 
to implement it is distributed over 
many classes. 


The CaffeineBeverage class runs 
the show; it has the algorithm, and 
protects it. 


The CaffeineBeverage class 
maximizes reuse among the 
subclasses. 


The algorithm lives in one place and 
code changes only need to be made 
there. 


The Template Method version provides 
a framework that other caffeine 
beverages can be plugged into. New 
caffeine beverages only need to 
implement a couple of methods. 

The CaffeineBeverage class 
concentrates knowledge about the 
algorithm and relies on subclasses to 
provide complete implementations. 
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Template Method Pattern defined 


You’ve seen how the Template Method Pattern works in our Tea and Coffee example; 
now, check out the official definition and nail down all the details: 


The Template Method Pattern defines the skeleton 
of an algorithm in a method, deferring some steps to 
subclasses. Template Method lets subclasses redefine 
certain steps of an algorithm without changing the 
algorithm’s structure. 


This pattern is all about creating a template for an algorithm. What’s a template? 

As you’ve seen it’s just a method; more specifically, it’s a method that defines an 
algorithm as a set of steps. One or more of these steps is defined to be abstract and 
implemented by a subclass. This ensures the algorithm’s structure stays unchanged, 
while subclasses provide some part of the implementation. 

Let’s check out the class diagram: 

TKc template mctKod makes use o( -the 
pV-imi-tivcOfCV-aiiohS io implement 
aljov-i-tKm. It is dcdouplcd -fvom the ad-tual 
irwflcrwCh-ta-tioh o( iKcsc opcv-atiohS. 
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template method pattern up close 


XJp Cl^se - 

Let’s take a closer look at how the AbstractClass is defined, including the template method 
and primitive operations. 


Here 一 ave ⑽ abstract 

■ 1S detlaved abstTatt a«d "'earvt to 

be subdassed bv dla^es that 「洲如 
，叶 1 ㈣ 山 oUhe 听 atw 


abstract class AbstractClass { 

final void templateMethod () { 

primitiveOperationl(); 
primitiveOperation2(); 
concreteOperation(); 


’“h example i wo 0 ( 
七 he p^rimiiivc op C Wi 0hS 
_七 be ir^plcmch-tcd by 
6o ^ic subclasses. 


I/Vc also Kave a coy\trtbc operation dc-fincd 
•m -tKc abstract dlass. /V|ov-c aboui tKcsc 
kinds o-f methods \v\ a bii - 


abs tract void primitiveOperationl() 

abstract void primitiveOperation2() 

void concreteOperation() { 

// implementation here 



Th « ^?\aie me-thod 

de + in « s eC[[Aenie ^ 

s ^eps, each vepvesen£ed 
b y a me-thod. 



Heves tV>e temyla-ke ">etV>od- |-t s 

detUed W to swbtl f StS 

代減 k 岣如 sev^ te ^ 
s-teys m tV>e 
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the template method pattern 



VayUp Cl^se 


Now we’re going to look even closer at the types of method that can go in the abstract class: 


mtWde 

J。 “讥 


abstract class AbstractClass { 



final void templateMethod () { 

primitiveOperationl(); 
primitiveOperation2(); 
concreteOperation(); 
hook(); 

} 


abstract void primitiveOperationl(); 


Wt still Kavc ouv primitive 
mcihods ； iKcsc art 
abs*tv*a 匕七 and implemcivted 
by subclasses. 


} 


abstract void primitiveOperation2(); 


final void concreteOperation () 
// implementation here 

} 



void hook() {} 

r 


A “ <i 七十十 

ab^atttla^ TW.s ' s ,f etlaved , 

It may be ^ m "'办 d 

W swbdasses - 


A ^ohdvctc mctKod, bu-fc l/Ve dah also Kavc do^dve-tc methods -tKa-t do ho-tK'mj 

••七 does ho-tK'mj/ by default; we dal I these \ooks. w Subdlasscs av-c -fvee 

to ovevv-ide these but do^i Kavc io. IVcVc 301^3 io 
s« Kow -these arc usc-ful oy\ -the hwt pa^c- 
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implement a hook 


Hooked oh 
Template Method... 

A hook is a method that is declared in the 
abstract class, but only given an empty 
or default implementation. This gives 
subclasses the ability to “hook into” the 
algorithm at various points, if they wish; a 
subclass is also free to ignore the hook. 

There are several uses of hooks; let’s take 
a look at one now. We’ll talk about a few 
other uses later: 



public abstract class CaffeineBeverageWithHook { 


final void prepareRecipe () { 
boilWater(); 
brew(); 
pourlnCup(); 

if (customerWantsCondiments()) 
addCondiments(); 

} 

} 

abstract void brew(); 
abstract void addCondiments(); 


吧， r :: 二糾 

丄 。七 


void boilWater() { 

System, out .println (''Boiling water"); 

} 

void pourInCup() { 

System, out .println (''Pouring into cup") 

} 


boolean customerWantsCondiments() 
return true; 

} 



a u 。 出―切 m 

Jwt 一 “… 


This is a Kook because -tKc 
subdlass dah override -tKis 
mctKod, bu-t doesn't Kavc -to. 
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Using the hook 


To use the hook, we override it in our subclass. Here, the hook controls whether 
the CafTeineBeverage evaluates a certain part of the algorithm; that is, whether 
it adds a condiment to the beverage. 

How do we know whether the customer wants the condiment? Just ask ! 


public class CoffeeWithHook extends CaffeineBeverageWithHook { 
public void brew() { 

System, out .printIn (''Dripping Coffee through filter"); 


public void addCondiments() { 

System. out. println (''Adding Sugar and Milk"); ^ y/V^cv-c ovcv*v*"»dc 

public boolean customerWantsCondiments () { ovm 切 

String answer = getUserlnput(); 


if (answer. toLowerCase () • startsWith ( 、 'y 〃） 
return true; 

} else { 

return false; 

} 


private String getUserlnput() 
String answer = null; 


the usev^s mfu-t ov\ 
"tKc dedisioh 

and \rctuv-h -tvuc ov- -false, 
dcpchdihj oy \ -fcKc mput 


System, out .print (''Would you like milk and sugar with your coffee (y/n) ?、') 

BufferedReader in = new BufferedReader(new InputStreamReader(System.in)); 
try { 

answer = in.readLine(); 

} catch (IOException ioe) { 

System, err .println (''10 error trying to read your answer"); 


if (answer == null) { 
return 、 'no"; 

} 

return answer; 


t 丁一 It : 二 taw 一 aw. 




一⑷ Ws 十 
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test drive 


Let's ruw the TestPrive 


Okay, the water's boiling... Here's the test code where 
we create a hot tea and a hot coffee 


public class BeverageTestDrive { 

public static void main(String[] args) { 


TeaWithHook teaHook = new TeaWithHook(); 

CoffeeWithHook coffeeHook = new CoffeeWithHook(); 


System, out .printIn (''\nMaking tea. ••"); 
teaHook.prepareRecipe(); 

System, out .printIn (''\nMaking coffee. . ； 

coffeeHook.prepareRecipe(); 


Cv-catc 3 *tc3- 

A«d tall yveyaveRedifeO 


And lets give it a row... 


File Edit Window Help send-more-honesttea 


% java BeverageTestDrive 


Making tea... 

Boiling water ^ o( tea, and yes, 

Steeping the tea douv-sc y/c y/atvt tha 七 lemon! 

Pouring into cup 

Would you like lemon with your tea (y/n)? y 
Adding Lemon 



Making coffee. . . a ^\tt not 

Boiling water 七 ^>ass oy\ "tV> 

Dripping Coffee through filter C.o^d» wC,n 

Pouring into cup 

Would you like milk and sugar with your coffee (y/n)? n 


㈣ 峡 
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the template method pattern 



Now, I would have thought 
that functionality like asking the 
customer could have been used by 
all subclasses? 


You know what? We agree with you. But you 
have to admit before you thought of that it was a 
pretty cool example of how a hook can be used 
to conditionally control the flow of the algorithm 
in the abstract class. Right? 

We’re sure you can think of many other more 
realistic scenarios where you could use the 
template method and hooks in your own code. 


When I’m creating a template 
method, how do I know when to use 
abstract methods and when to use 
hooks? 

Use abstract methods when your 
subclass MUST provide an implementation 
of the method or step in the algorithm. 

Use hooks when that part of the algorithm 
is optional. With hooks, a subclass may 
choose to implement that hook, but it doesn’t 
have to. 

What are hooks really supposed 
to be used for? 

There are a few uses of hooks. As 
we just said, a hook may provide a way for 
a subclass to implement an optional part 


DumffcJiiestiPiis 

of an algorithm, or if it isn’t important to 
the subclass' implementation, it can skip 
it. Another use is to give the subclass 
a chance to react to some step in the 
template method that is about to happen, 
or just happened. For instance, a hook 
method like justReOrderedList() allows the 
subclass to perform some activity (such as 
redisplaying an onscreen representation) 
after an internal list is reordered. As you’ve 
seen a hook can also provide a subclass 
with the ability to make a decision for the 
abstract class. 


Does a subclass have to 
implement all the abstract methods in the 
AbstractClass? 

Yes, each concrete subclass defines 
the entire set of abstract methods and 


provides a complete implementation of the 
undefined steps of the template method’s 
algorithm. 

It seems like I should keep my 
abstract methods small in number, 
otherwise it will be a big job to implement 
them in the subclass. 

That’s a good thing to keep in 
mind when you write template methods. 
Sometimes this can be done by not making 
the steps of your algorithm too granular. But 
it’s obviously a trade off: the less granularity, 
the less flexibility. 

Remember, too, that some steps will be 
optional; so you can implement these as 
hooks rather than abstract methods, easing 
the burden on the subclasses of your 
abstract class. 
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the hollywood principle 


The Hollywood Principle 

We’ve got another design principle for you; it’s called the 
Hollywood Principle: 


you’ve heard me say it 
before, and I’ll say it again ： 
don't call me, I’ll call you! 



Easy to remember, right? But what has it got to do with OO 
design? 

The Hollywood principle gives us a way to prevent 
“dependency rot.” Dependency rot happens when you have 
high-level components depending on low-level components 
depending on high-level components depending on sideways 
components depending on low-level components, and so on. 
When rot sets in, no one can easily understand the way a 
system is designed. 



With the Hollywood Principle, we allow low-level components 
to hook themselves into a system, but the high-level 
components determine when they are needed, and how. In 
other words, the high-level components give the low-level 
components a “don’t call us, we’ll call you” treatment. 



torh-o 


A 卜 _ level ^ ?onef ,i hevev . 
Mils a hi 3 h-| e v e | 

directly. 
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The Hollywood Principle avid Template Method 


The connection between the Hollywood Principle and the Template Method Pattern is probably somewhat 
apparent: when we design with the Template Method Pattern, we’re telling subclasses ， “don’t call us, we’ll call 
you.” How? Let’s take another look at our CaffeineBeverage design: 


|tV,as ove^r 

il 融 一 7 “ 帅 e : eeded 。 

，—⑽ — J a "'⑽ 



CaffeineBeverage 


prepareRecipe() 

boilWater() 

pourlnCup() 

brew() 

addCondimentsQ 


^°^cic Tea 0 \r r^CC 

代 T c ^ ee> ^ 

.. c ， e P e "de. 1 di es if) 

斷 a || , ysietn the 



Coffee 


Tea 

brew() 

addCondimentsQ 


brew() 

addCondiments() 




Tea WCo ««7 
tail tV,e abs-traft tlass 
di 代出”办 叫 
''tailed" 心 ㈡ 七 . 




What other patterns make use of the Hollywood Principle? 


乙 SJ9LJ10 Aue : J8AJ8SqO ‘pOL]19|/\| AjOpBJ 91 ] 丄 
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who does what 


DumPc^uestiPiis 

How does the Hollywood Principle 
relate to the Dependency Inversion 
Principle that we learned a few chapters 
back? 

The Dependency Inversion 
Principle teaches us to avoid the use of 
concrete classes and instead work as 
much as possible with abstractions. The 
Hollywood Principle is a technique for 
building frameworks or components so that 
lower-level components can be hooked 


into the computation, but without creating 
dependencies between the lower-level 
components and the higher-level layers. So, 
they both have the goal of decoupling, but 
the Dependency Inversion Principle makes a 
much stronger and general statement about 
how to avoid dependencies in design. 

The Hollywood Principle gives us a 
technique for creating designs that allow 
low-level structures to interoperate while 
preventing other classes from becoming too 
dependent on them. 


Is a low-level component 
disallowed from calling a method in a 
higher-level component? 

Not really. In fact, a low level 
component will often end up calling a method 
defined above it in the inheritance hierarchy 
purely through inheritance. But we want to 
avoid creating explicit circular dependencies 
between the low-level component and the 
high-level ones. 


♦ + Cf + 

- O 办轚孓 WMATT - ? 

Match each pattern with its description: 

Pattern Description 


Encapsulctte Irrtercjicingecible 

Teniplcite betaViPrs cind use dele^cttipn i9 

decide which beliaViPr tP use 


Strategy 


Subclcisses decide 
i 9 Implement steps In an 
algpritlini 



Subclcisses decide which 
concrete clcisses tP create 
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Template Methods iw the Wild 


The Template Method Pattern is a very common pattern and 
you’re going to find lots of it in the wild. You’ve got to have 
a keen eye, though, because there are many implementations 
of the template methods that don’t quite look like the 
textbook design of the pattern. 

This pattern shows up so often because it’s a great design tool 
for creating frameworks, where the framework controls how 
something gets done, but leaves you (the person using the 
framework) to specify your own details about what is actually 
happening at each step of the framework’s algorithm. 

Let’s take a little safari through a few uses in the wild (well, 
okay, in the Java API)... 


- ^ 

/ In training, we study the <^ 
classic patterns. However, 、 
{ when we are out in the real world, we 
V must learn to recognize the patterns 
/ out of context. We must also learn 
V to recognize variations of patterns, 

、 I because in the real world a square 
\ hole is not always truly square. 

o 

0 
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sorting with template method 


Sorting with Template Method 

What’s something we often need to do with arrays? 

Sort them! 

Recognizing that, the designers of the Java Arrays class 
have provided us with a handy template method for 
sorting. Let’s take a look at how this method operates: 

吣 attuallv have two me tV,ods a,d adt t 亨 tW to 

^v-ov'idc sort -fu^tiorval'i-tY- 


lA^’ve \>avcd 七 Wis 

todlc a Irttlc -to make \i 
casicv- {jo Y ou d 

like to see d\\, gv-ab 
the souvd-C -fv-om 3 r\d 
it ou 七 … 




TV , e - e ^ od , soj ( V-s ysU 工二\ a ” 


public static void sort (Object[] a) { 
Object aux[] = (Object[])a.clone(); 
mergeSort(aux, a, 0, a.length, 0); 


} 


private static void mergeSort(Object sre [], Object dest[], 
int low, int high, int off) 


TKc mcvjcSovtO mctKod 乙 otvtams -tKc sort aljovi-tKm, and v-dics 
oy\ dh o-f -tKc tompavcToO mc-tKod -to dom^lctc *tKc 

aljov-i-tKm. l-f you’ve m-teves-ted m -tKc nitty gvi-t-ty o-f Kov/ -tKc 
sovt'mj Kaf^ChS, you 11 v/3»vt to dKcdk out -tKc Sun souv-dc Code 

TKihk of -this as -fcKc 
mciKod. 


for (int i=low; i<high; i++){ 
for (int j=i; j>low && 

((Comparable)dest[j-1]).compareTo((Comparable)dest[j])>0; 


j —) 


swap(dest. 


-1)； 


} 

return; 


Th !f is a ^°^ie mclhod, alv-eady 
dcUed ih the /Ways class. 


dorwPavcToO »s method >wc 
y^ccd -to — 七七 O U ⑽七 

七 he template mc-t^od. 


300 Chapter 8 



the template method pattern 


WeVe got some ducks to sort... 


Let’s say you have an array of ducks that you’d like to sort. How 
do you do it? Well, the sort template method in Arrays gives us the 
algorithm, but you need to tell it how to compare ducks, which you do by 
implementing the compareToQ method... Make sense? 





No, it doesn't. Aren't 
we supposed to be 
subclassing something? I thought 
that was the point of Template 
Method. An array doesn't subclass 
anything, so I don't get how wed 
use sortQ. 


sot ah avv-ay o( 


Du^ks 


heed +0 sov-t 


Good point. Here’s the deal: the designers of sort() wanted it 
to be useful across all arrays, so they had to make sort。a static 
method that could be used from anywhere. But that’s okay, 
it works almost the same as if it were in a superclass. Now, 
here is one more detail: because sort。really isn’t defined in 
our superclass, the sort() method needs to know that you’ve 
implemented the compareToO method, or else you don’t have 
the piece needed to complete the sort algorithm. 


To handle this, the designers made use of the Comparable 
interface. All you have to do is implement this interface, which 
has one method (surprise): compareToQ. 


What is comparetoO? 


The compareToQ method compares two objects and returns whether one is less than, greater than, 
or equal to the other. sortQ uses this as the basis of its comparison of objects in the array. 
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Comparing Pucks and Pucks 

Okay, so you know that if you want to sort Ducks, 
you’re going to have to implement this comp are ToQ 
method; by doing that you’ll give the Arrays class 
what it needs to complete the algorithm and sort your 
ducks. 

Here’s the duck implementation: 



v/c to c ” 七仏 c Comparable 

m-tcr-fatc smte ^ally subtlassmj. 


public class Duck implements Comparable 
String name; 
int weight; 

public Duck(String name, int weight) 
this.name = name; 
this.weight = weight; 

} 


public String toString () { 

return name + '' weighs 

} 


weight; 


Ouv- Pudks Kave a name and a v/eigVvt 


* 七 simple ； all Duties do 

•is 七 的 a»«c ar\d 'wcigV^-t! 


public int compareTo(Object obj 


ect) { 

Duck otherDuck = (Duck)obj ect; <- - - - 


Okay, V>cvcs ^ai sor-t ” 《 ds … 

tom^av*cToO -takes ano-t^cv* Dudk 七。 dorw\>avc THIS Pudk 七 o. 


if (this.weight < otherDuck.weight) { 

return -1; 

} else if (this.weight == otherDuck.weight) 
return 0; 

} else { // this.weight > otherDuck.weight 
return 1; 

} 


^Hcvcs v/Kcvc v/c s|>cdi-fy Kov/ Pudks 

tom\>avc- l-f THIS Pudk v/cijKs less 
oiKcvPudk v/c vetuv^ -I; 
i-f -tKcy avc c<\ual, vc-tuv^ O', and i-f 
THIS Pudk y/ei^s move, v/C vetuvn I- 
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Let's sort some Pucks 

Here’s the test drive for sorting Ducks... 


public class DuckSortTestDrive { 

public static void main(String[] args) { 
Duck[] ducks = { 


new 

Duck ( 

、、 Daffy 〃， 

8), 

new 

Duck ( 

、、 Dewey", 

2), 

new 

Duck ( 

、、 Howard 〃 

,V , 

new 

Duck ( 

、、 Louie 〃， 

2), 

new 

Duck ( 

、、 Donald 〃 

,10), 

new 

Duck ( 

、 'Huey", 

2) 


以二4 


Noh 匕 c -that wc 

匕 a 11 Arrays' s-taiid 

wthod so\ri, ahd 
pass ii ouv- Dudks. 



System, out .printIn (''Before 
display(ducks); 

Arrays.sort(ducks); 


sorting :”）； 



Lets 七 io sec 
ttciv ” awes and y/eij^is. 


("t s sovt "tirwc/ 


System, out .printIn (''\nAfter 
display(ducks); 


sorting : 〃）； 


Let’s 七 ttem (a^a'm) io see 
W，V rvames a»rvd 


public static void display(Duck[] ducks) { 
for (int i = 0; i < ducks.length; i++) { 

System.out.println(ducks[i]); 


Let the sorting commence! 


I File Edit Window Help DonaldNeedsToGoOnADiet 


% java DuckSortTestDrive 

Before sorting : 

Daffy weighs 8 

D ewey weighs 2 D^ h 

Howard weighs 7 

Louie weighs 2 

Donald weighs 10 

Huey weighs 2 

After sorting : 

Dewey weighs 2 
Louie weighs 2 

Huey weighs 2 丁 soried P/ks 

Howard weighs 7 
Daffy weighs 8 
Donald weighs 10 
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behind the scenes: sorting ducks 


The making of the sorting duck machine 


Let’s trace through how the Arrays sort() template 
method works. We’ll check out how the template 
method controls the algorithm, and at certain 
points in the algorithm, how it asks our Ducks to 
supply the implementation of a step... 


First, we need an array of Ducks: 


❺ 


Duck [ ] ducks = {new Duck (、'Daf fy 〃， 8). 


Then we call the sortO template method in the Array 
class and pass it our ducks: 

Arrays.sort(ducks); 、 ____ 

The sortO method (and its helper mergeSortO) control 
the sort procedure. 


BeMnd 囊 

ike Scenes^ 





) 

The sovtO method dotvbroU 
•the aljovi'tV)W', r\o d.lass d.3r\ 
-tWis. sortO douivts 
on a Com\>avablc tlass -to 
^vovidc inr»^lcw'Cr\'t3'tior\ <Jc 
dorw^avcToO 


❺ 


O 

❺ 


To sort an array, you need to compare two items one 
by one until the entire list is in sorted order. 


When it comes to comparing two ducks, the sort 
method relies on the Duck’s compareToO method 
to know how to do this. The compareToO method 
is called on the first duck and passed the duck to be 
compared to: 


ducks[0].compareTo(ducks[1]); 


Fivs-t 






pudk -to tonr^avc i 七 to 


If the Ducks are not in sorted order, they’re swapped with 
the concrete swapO method in Arrays: 
swap() 



The sort method continues comparing and swapping Ducks 
until the array is in the correct order! 


Duck 

compareToO 

toString() 

/ No unlike 

I a ic—aic 
/ method- 

Arrays 

sort() 

swap() 
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the template method pattern 


_tfcerei£irenp 

Dumb Questipns 


Is this really the Template 
Method Pattern, or are you trying too 
hard? 

The pattern calls for implementing 
an algorithm and letting subclasses supply 
the implementation of the steps - and the 
Arrays sort is clearly not doing that! But, 
as we know, patterns in the wild aren’t 
always just like the textbook patterns. They 
have to be modified to fit the context and 
implementation constraints. 

The designers of the Arrays sort() method 
had a few constraints. In general, you can’t 
subclass a Java array and they wanted the 
sort to be used on all arrays (and each array 
is a different class). So they defined a static 
method and deferred the comparison part of 


the algorithm to the items being sorted. 

So, while it’s not a textbook template 
method, this implementation is still in the 
spirit of the Template Method Pattern. Also, 
by eliminating the requirement that you have 
to subclass Arrays to use this algorithm, 
they’ve made sorting in some ways more 
flexible and useful. 

This implementation of sorting 
actually seems more like the Strategy 
Pattern than the Template Method 
Pattern. Why do we consider it 
Template Method? 

You’re probably thinking that 
because the Strategy Pattern uses object 
composition. You’re right in a way- we’re 


using the Arrays object to sort our array, so 
that’s similar to Strategy. But remember, 
in Strategy, the class that you compose 
with implements the entire algorithm. The 
algorithm that Arrays implements for sort 
is incomplete; it needs a class to fill in the 
missing compareTo() method. So, in that 
way, it’s more like Template Method. 

Are there other examples of 
template methods in the Java API? 

Yes, you'll find them in a few 
places. For example, java.io has a read() 
method in InputStream that subclasses 
must implement and is used by the tempate 
method read(byte b[], int off, int len). 


We know that we should favor composition over inheritance, right? Well, the implementers of the 
sort() template method decided not to use inheritance and instead to implement sort() as a static 
method that is composed with a Comparable at runtime. How is this better? How is it worse? How 
would you approach this problem? Do Java arrays make this particularly tricky? 


Think of another pattern that is a specialization of the template method. In this specialization, primitive 
operations are used to create and return objects. What pattern is this? 
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the paint hook 


Swiwgiw' with Frames 

Up next on our Template Method safari... keep your eye out for swingingJFrames! 

If you haven’t encountered JFrame, it’s the most basic Swing container and inherits 
a paintQ method. By default, paintO does nothing because it’s a hook'. By overriding 
paintQ, you can insert yourself into JFrame’s algorithm for displaying its area of the 
screen and have your own graphic output incorporated into the JFrame. Here’s 
an embarrassingly simple example of using a JFrame to override the paintQ hook 



method: 



public class MyFrame extends JFrame { 


a 外 datcO 从 a 七 do^ols 

algorism -fov- u^da-tmg ttc 

^ V^ook mio 从 a 七 alfi 七 w b7 
ovcwd'rnj ?am 七 (Hook 你 etV>od. 


^ - 

public MyFrame(String title) { 
super(title); 

this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); 


Po^-t look bcWmd 
duv-b'm! Jus-t some 


this.setSize(300,300); 
this.setVisible(true); 



public void paint(Graphics graphics) { 
super.paint(graphics); 

String msg =、、I rule!!"; 

graphics•drawstring(msg, 100, 100); 


Jpvame's update a—Uls ya'mtO. By 
de-fa«*lt, yamtO does notWy . 沾 a Wk. 
l^ e Ve ovevvid'mj ya'mtO, a«d tell'mj the 

Jpvame to dva>N a wessaje m the Wmdo>N. 


public static void main(String[] args) { 

MyFrame myFrame = new MyFrame (''Head First Design Patterns"); 


0 O O Head First Design Patterns 


I rule!! 


tr 


p Heve’s the message 七^七 , 
? amicd m because “ve 

looked m-to i\\t 七 (） 
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Applets 

Our final stop on the safari: the applet. 

You probably know an applet is a small program that runs in a web page. Any 
applet must subclass Applet, and this class provides several hooks. Let’s take a look 
at a few of them: 



public class MyApplet extends Applet 
String message; 


{ 



The mit Uok allows the ayfleU® Ao^ai^cy 

■，i to the a ?? lettV» e W- 


public void init() { 

message = ''Hello World, 
repaint(); ^ - 


I f m alive !〃； 


rc^am-tO is d tomtit mc-t^od m i\\t A??lc 七 
y dlass i\iai Ic-U U 汗 c 卜 level 

weds to be redraw 


public void start() { 

message = ''Now I’m starting up..."; 
repaint (); 


TKc s-tavi Kook allows iKc applet to do 
somctKmj v/Kch -the apf let is just about 
to be displayed oy\ -tKc v/eb page- 


public void stop() 
message = ''0h f 
repaint (); 


now I r m being stopped ..; 



,e wev yes to a«otV>ev ya^e, lV>e 


public void destroy() { 

// applet is going away... 

} 

public void paint(Graphics g) { 
g.drawstring(message, 5, 15); 

} 



"tKc dcstv-oy Kook is used -tKc applet 
is 50 'mj -to be des-t^royed, say, v/Kch iKc bv-ov/sev 
paw is closed. Wt dould tv-y -to display 
somc-tKmj Kcv-c, bui v/Kat v/ould be iKc poihi? 


V IA/ e || looky heve! Ouv-old ^vie«d tV>e 

?a i«Hd! aUo »-akes 

use tV>is mettiod as a V»®ok. 


Concrete applets make extensive use oi kooks to supply tkeir 
own tekaviors. Because tkese metkocJs are implementect as 
kooks, tke applet isn’t reejuirect to implement tkem. 
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Fireside Chats 


Tonight’s talk ： Template Method and Strategy 
compare methods. 


Template Method 

Hey Strategy, what are you doing in my 
chapter? I figured I’d get stuck with someone 
boring like Factory Method. 



Nope, it’s me, although be careful - you and 
Factory Method are related, aren’t you? 

I was just kidding! But seriously, what are you 
doing here? We haven’t heard from you in eight 

chapters! I’d heard you were on the final draft of your 

chapter and I thought I’d swing by to see how 
it was going. We have a lot in common, so I 
thought I might be able to help... 

You might want to remind the reader what 
you’re all about, since it’s been so long. 

I don’t know, since Chapter 1 ， people have 
been stopping me in the street saying, “Aren’t 
you that pattern...” So I think they know who 
I am. But for your sake: I define a family of 
algorithms and make them interchangeable. 
Since each algorithm is encapsulated, the client 
can use different algorithms easily. 

Hey, that does sound a lot like what I do. But 
my intent’s a little different from yours; my job 
is to define the outline of an algorithm, but 
let my subclasses do some of the work. That 
way，I can have different implementations of an 
algorithm’s individual steps, but keep control 
over the algorithm’s structure. Seems like you 

have to give up control of your algorithms. I'm not sure I'd put it quite like that... and 

anyway, I’m not stuck using inheritance for 
algorithm implementations. I offer clients a 
choice of algorithm implementation through 
object composition. 
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Template Method 

I remember that. But I have more control over 
my algorithm and I don’t duplicate code. In fact, 
if every part of my algorithm is the same except 
for, say, one line, then my classes are much more 
efficient than yours. All my duplicated code 
gets put into the superclass, so all the subclasses 
can share it. 


Yeah, well, I’m real happy for ya，but don’t 
forget I’m the most used pattern around. 

Why? Because I provide a fundamental 
method for code reuse that allows subclasses to 
specify behavior. I’m sure you can see that this 
is perfect for creating frameworks. 


How’s that? My superclass is abstract. 


Like I said Strategy, I’m real happy for you. 
Thanks for stopping by, but I’ve got to get the 
rest of this chapter done. 


Strategy 


You might be a little more efficient (just a little) 
and require fewer objects. And you might also 
be a little less complicated in comparison to 
my delegation model，but I’m more flexible 
because I use object composition. With me, 
clients can change their algorithms at runtime 
simply by using a different strategy object. 
Come on, they didn’t choose me for Chapter 1 
for nothing! 


Yeah, I guess... but, what about dependency? 
You’re way more dependent than me. 


But you have to depend on methods 
implemented in your superclass, which are part 
of your algorithm. I don’t depend on anyone; 

I can do the entire algorithm myself! 


Okay ， okay ， don’t get touchy. I’ll let you 
work, but let me know if you need my special 
techniques anyway, I’m always glad to help. 


Got it. Don’t call us, we’ll call you... 
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crossword puzzle 



It’s that time again.... 



Across 

1. Strategy uses_rather than 

inheritance 

4. Type of sort used in Arrays 

5. The JFrame hook method that we overrode to 
print "I Rule" 

6. The Template Method Pattern uses 

_to defer implementation to other 

classes 

8. Coffee and_ 

9. Don't call us, we'll call you is known as the 
_Principle 

12. A template method defines the steps of an 


13. In this chapter we gave you more 


14. The template method is usually defined in an 

_class 

16. Class that likes web pages 


Down 

2. _algorithm steps are implemented 

by hook methods 

3. Factory Method is a_of 

Template Method 

7. The steps in the algorithm that must be 
supplied by the subclasses are usually declared 


8. Huey, Louie and Dewey all weigh_ 

pounds 

9. A method in the abstract superclass that does 
nothing or provides default behavior is called a 
_method 

10. Big headed pattern 

11. Our favorite coffee shop in Objectville 

15. The Arrays class implements its template 
method as a_method 
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Tools for your design Toolbox 

/ We’ve added Template Method to your toolbox. With 
Template Method you can reuse code like a pro while 
keeping control of your algorithms. 




00 ?v'w^ cs ■ 

一 :: 一 ^ 

♦ 身於 I 

二 “。—“加 一 

de 〆 

晌 ㈣ - ws . 




-\\ vi^ur sv 


一 、 

r w w _ a t>w sV ^， s 。 ‘二 

a 二工 


^[y\A ouv newest \>att 价 

lets d-lasscs »m\>lc«^cr\t>^3 
an aljovi-bV^^ At(cr some 
stc^s *to subclasses. 


skeieW ^ ? to s-»bt\asses- 



BULLET POINTS 


A “template method” defines 
the steps of an algorithm, 
deferring to subclasses for the 
implementation of those steps. 

The Template Method 
Pattern gives us an important 
technique for code reuse. 

The template method’s 
abstract class may define 
concrete methods, abstract 
methods and hooks. 

Abstract methods are 
implemented by subclasses. 

Hooks are methods that do 
nothing or default behavior in 
the abstract class, but may be 
overridden in the subclass. 

To prevent subclasses from 
changing the algorithm in the 
template method, declare the 
template method as final. 

The Hollywood Principle guides 
us to put decision-making in 
high-level modules that can 
decide how and when to call 
low level modules. 

You’ll see lots of uses of the 
Template Method Pattern in 
real world code, but don’t 
expect it all (like any pattern) to 
be designed “by the book.” 

The Strategy and Template 
Method Patterns both 
encapsulate algorithms, one 
by inheritance and one by 
composition. 

The Factory Method is a 
specialization of Template 
Method. 
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Exercise 

solutions 


Sharpen your pencil 


Draw the new class diagram now that we’ve moved 
prepareRecipe() into the CaffeineBeverage class: 



♦ 


♦ WM 办 O 备鬌孓 


Match each pattern with its description: 

Pattern 


Template M©tliPcI 


Strgt©^/ 


Factory M&th^d 


Description 



Encapsulate intercjian^abl© 
befeaViors and us© deleg^tiQn tP 
decide wliicfe befeaViPr tP us© 


Subclasses decide fep\V 
implement st&ps In an 
algorithm 


Subclasses decide which 
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Exercise solutions 


the template method pattern 
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9 the Iterator and Composite Patterns 

命 Well-Managed + 

Collections ♦ 



There are lots of ways to stuff objects into a collection. Put them 

in an Array, a Stack, a List, a Hashtable, take your pick. Each has its own advantages and 
tradeoffs. But at some point your client is going to want to iterate over those objects, and 
when he does, are you going to show him your implementation? We certainly hope not! 
That just wouldn’t be professional. Well, you don’t have to risk your career; you’re going 
to see how you can allow your clients to iterate through your objects without ever getting 
a peek at how you store your objects. You’re also going to learn how to create some 
super collections of objects that can leap over some impressive data structures in a single 
bound. And if that’s not enough, you’re also going to learn a thing or two about object 
responsibility. 


this is a new chapter 
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big news 


Breaking News: Objectville Vmr and 
Objectville Pancake House Merge 

That’s great news! Now we can get those delicious pancake breakfasts at the 
Pancake House and those yummy lunches at the Diner all in one place. But, 
there seems to be a slight problem... 



... but we can’t agree on 
how to implement our menus. 

That joker over there used an 
ArrayList to hold his menu items, and 
I used an Array. Neither one of us is 
willing to change our implementations., 
we just have too much code written 
that depends on them. 


O 
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Check out the Menu Items 


At least Lou and Mel agree on the 
implementation of the Menultems. 
Let’s check out the items on each 
menu, and also take a look at the 
implementation. 



Uile tv,e Parvtake House o+ 

Wa 敲 'W ㈣ 

I 丄 ..AM A PVltC 


public class Menultem { 
String name; 

String description; 
boolean vegetarian; 
double price; 



OLjedville 2 ) ( 


m&L 


Vegetarian BLT 

(FakirV) Bacon witl-' 
whole wheat 

blt 

B ^con with lettuce 

S °upoftheday 

Ab owlofthesoupc 

HotOog° fPOtatOSala 

A hot dog, with saud 

to PP e d with cheese 

Stea A med Veggies andt 

A ^dley of steamed 




\OlyedvilIe Pancake JJoLLse 


Regular Pen 


ncake Bre a kf ast 


Pancakes with fried 


e 99 s / sausage 


2.99 


B，Ueberr y Pancakes 


and blueberry syrup 

Waffles 

Waf fles,wit hyourchi 


berries, 


or strawberrie 


aceofbluebi 


3.59 


'ernes 


public Menultem(String name. 

String description, 
boolean vegetarian, 
double price) 

{ 

this.name = name; 
this.description = description; 
this.vegetarian = vegetarian; 
this.price = price; 


A M ⑽ /ie … dohsisls rS 3 

a 〜 to ihdicK 私广 e, a des 广 中 仏〜 

^ PH^e. /ou 1 : r ,s y ei3 ^ 

一 w 。 … 』 al 二 ㈣ 


public String getName() { 

return name; 


public String getDescription() { 

return description; 

} 

public double getPrice() { 
return price; 


public boolean isVegetarian() { 

return vegetarian; 



TKcsc Jcttcv- mrbv^ods 
let you aucss kids 
o( tV^c •七 


} 
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two menus 


Lou and Mel's Menu implementations 


Now let’s take a look at what Lou and Mel are 
arguing about. They both have lots of time and 
code invested in the way they store their menu 
items in a menu, and lots of other code that 
depends on it. 



衿 eve、Lous imylementatiorv tv>e 


Pa^akc House 



public class PancakeHouseMenu { 

ArrayList menultems; 

public PancakeHouseMenu () { ^- -- 

menultems = new ArrayList(); 


Lo\as us'mj /\vvayLis-t "to siov-c 
his items 



addltem (''K&B^ s Pancake Breakfast", 


''Pancakes with scrambled eggs, and toast". 


true, 

2 . 99 ); <： — 

addltem (''Regular Pancake Breakfast", 

''Pancakes with fried eggs, sausage", 
false, 

2 . 99 ); 



item is added to -bV^c 

AvvaYUst 

tatV> Mervwl'te"' ^ a a 

destv-i^iow, YiV>etV>ev ov its a 
心 iW , 补 d 如…“ 


addltem (''Blueberry Pancakes", 

''Pancakes made with fresh blueberries", 
true, 

3 . 49 ); 


addltem (''Waffles ”， 

''Waffles, with your choice of blueberries or strawberries", 
true, 

3 . 59 ); 


丁 。add a Tf m eat “r 

a ， d^ adds，t 〉 


public void addltem(String name. String description, 
boolean vegetarian, double price) 

{ 

Menultem menultem = new MenuItem(name, description, vegetarian, price); 
menultems.add(menultem); 

} 

/—The wt/Vley.ullemsO »elWd veiu^s Ue lisl o( ^ itew 

public ArrayList getMenuItems () { hC ^ 

return menultems; 

{jo Kavc -to vcwv'rbc all 从 at todt. 


II other menu methods here 
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Haah! An Arraylist... I 
used a REAL Array so I can 
control the maximum size of my menu 
and get my Menultems without 
having to use a cast. 


s 


/\Zj C Vs 


oUk P i 


mCV- 




public class DinerMenu { 

static final int MAX—ITEMS 
int numberOfItems = 0; 
Menultem[] menultems; 


如 ms out Vi 七“七 ha— 七 o ⑶七 W ob^tU- 


public DinerMenu() { 

menultems = new Menultem[MAX ITEMS] 


— Like Lou, Mel dv-catcs Kis menu items m 

donstvud'tov, usmj "tV>C add|"tcm() method- 

addltem(''Vegetarian BLT ’’， 

''(Fakin ’） Bacon with lettuce & tomato on whole wheat", true, 2.99); 
addltem ( 、 'BLT", 

''Bacon with lettuce & tomato on whole wheat", false, 2.99); 
addltem (''Soup of the day 〃， 

''Soup of the day, with a side of potato salad” ， false, 3.29); 
addltem (''Hotdog", 

''A hot dog, with saurkraut, relish, onions, topped with cheese", 
false, 3.05); 

// a couple of other Diner Menu items added here 

} _ addl-tc^O -takes all tV>c ^avametev-s 

^ 时⑽ a” to tveate a/VM 七 em awl 

public void addltem (String name. String description, 'ms-bay\tia*bcs or\t- It also d.V^ctks to make 

boolean vegetarian, double price) suv - c Wrt 七 he mewu s'iz^ W>t 


Menultem menultem = new Menultem(name, description, vegetarian, price); 1 
if (numberOfItems >= MAX ITEMS) { 


System.err .println (''Sorry, menu is full! 
} else { 

menultems [numberOf Items ] = menu I tern; 
numberOfItems = numberOfItems + 1; 


Can't add item to menu ”)； 

spcdi-pidally v/3h*ts "to keep Kis mchu Uhdcv* 3 
dc\rbih Siz£ (presumably so k docs^i Kavc to 
VCmcmbcV "too rwa^y ^Cdipcs). 


public Menultem [] getMenuItems () { ^i/VleMlierrsO veiuyws -tKe avvay o-f menu i-tems. 

return menultems; 


// other menu methods here 


Like Lou, Md Has a bu^dK o( todt tKa-t dc^c^ds or\ -tKc o-f 

Kis menu bemj A^v-ay- HVs {joo busy dookmj -to vowvi-tc all tKis. 
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java enabled waitress 


Whafs the problem with having two different 
menu represewtatiows? 


To see why having two different menu representations complicates 
things, let’s try implementing a client that uses the two menus. 

Imagine you have been hired by the new company formed by the 
merger of the Diner and the Pancake House to create a Java-enabled 
waitress (this is Objectville, after all). The spec for the Java-enabled 
waitress specifies that she can print a custom menu for customers on 
demand, and even tell you if a menu item is vegetarian without having 
to ask the cook — now that’s an innovation! 

Let’s check out the spec, and then step through what it might take to 
implement her... 


The Java-Enabled Waitress Specification 




^ T^e W 
WaiW 
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Let’s start by stepping through how we’d implement the printMenuO method: 


To print all the items on each menu, you’ll need to call the getMenuItemO 
method on the PancakeHouseMenu and the DinerMenu to retrieve their 
respective menu items. Note that each returns a different type: 


PancakeHouseMenu pancakeHouseMenu = new PancakeHouseMenu() 
ArrayList breakfastIterns = pancakeHouseMenu.getMenuItems() 


DinerMenu dinerMenu = new DinerMenu(); 

Menultem[] lunchltems = dinerMenu•getMenuItems(); 



丁 V>c wctV^od Us 
•tV\c sawe ， Wb 如 
tails av-c 


"The irwplcrwc»vta-tioh 
,s show'mg ttvough, 
bvcak-fas*t i"tcrws avc 
•m 如 Avv-ayLis-t, lu^h 
items arc in ah Av*v*ay. 


O 


Now, to print out the items from the PancakeHouseMenu, we’ll loop through the 
items on the breakfastltems ArrayList. And to print out the Diner items we’ll 


loop through the Array. 

for (int i = 0; i < breakfastltems.size(); i++) { 

Menultem menultem = (Menultem)breakfastltems.get(i) 
System, out .print (menultem. getName () + '、'、）； 

System.out .println (menultem.getPrice () + '、'、）； 
System.out.printIn(menultem.getDescription()); 



Kov/, V>3vc to 

•i—CmCrrb two 

\ooys ho s 七吓 七 Wo— 
七 he W 

Jc rte 眯 s... 


for (int i = 0; i < lunchltems•length; i++) { 

Menultem menultem = lunchltems[i]; 

System, out .print (menultem. getName () + '、'、）； 
System, out .println (menultem. getPrice () + '、'、）； 
System.out.println(menultem.getDescription()); 


K 


… one loo^ -for "tKc 
AvvayLisi... 



and -Pov 

tKc Avvay- 


Implementing every other method in the Waitress is going to be a variation of 
this theme. We’re always going to need to get both menus and use two loops to 
iterate through their items. If another restaurant with a different implementation 
is acquired then we’ll have three loops. 
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whafs the goal 



Based on our implementation of printMenuO, which of the following apply? 


Q A. We are coding to the 

PancakeHouseMenu and DinerMenu 
concrete implementations, not to an 
interface. 

Q B. The Waitress doesn’t implement the 
Java Waitress API and so she isn’t 
adhering to a standard. 

Q C. If we decided to switch from using 

DinerMenu to another type of menu 
that implemented its list of menu items 
with a Hashtable, we’d have to modify 
a lot of code in the Waitress. 


Q D. The Waitress needs to know how each 

menu represents its internal collection of 
menu items; this violates encapsulation. 

Q E. We have duplicate code: the printMenuO 
method needs two separate loops to 
iterate over the two different kinds of 
menus. And if we added a third menu, 
we’d have yet another loop. 

Q F. The implementation isn’t based on 
MXML (Menu XML) and so isn’t as 
interoperable as it should be. 


What wow? 

Mel and Lou are putting us in a difficult position. They don’t want to change their 
implementations because it would mean rewriting a lot of code that is in each respective menu 
class. But if one of them doesn’t give in, then we’re going to have the job of implementing a 
Waitress that is going to be hard to maintain and extend. 

It would really be nice if we could find a way to allow them to implement the same interface for 
their menus (they’re already close, except for the return type of the getMenuItemsO method). 
That way we can minimize the concrete references in the Waitress code and also hopefully get 
rid of the multiple loops required to iterate over both menus. 

Sound good? Well, how are we going to do that? 
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Caw we encapsulate the iteration? 

If we’ve learned one thing in this book, it’s encapsulate what varies. It’s obvious 
what is changing here: the iteration caused by different collections of objects 
being returned from the menus. But can we encapsulate this? Let’s work 
through the idea... 

❹ To iterate through the breakfast items we use the sizeQ and get() 
methods on the ArrayList ： 


for (int i = 0; i < breakfastIterns. size (); i++) { 

Menultem menuItem = (Menultem)breakfastlterns.get(i) 



❾ And to iterate through the lunch items we use the Array length field and 
the array subscript notation on the Menultem Array. 


Array 



A^ay of 
A1cnu|*tcrwS. 




you are here ► 323 



encapsulating iteration 


❽ Now what if we create an object, lefs call it an Iterator, 
that encapsulates the way we iterate through a 
collection of objects? Lefs try this on the ArrayList 



Iterator iterator = breakfastMenu.createlterator() 


IVc ask -the brcak-fas-t/l/Icnu 
•for 釙 itev-a-tov- of its 
/^ler\uHcms. 

r 


while (iterator. hasNext () ) { ^ aile iWe aire 1 «化 

MenuItem menultem = (Menultem)iterator.next(); 

I 

> 


next() 


get -the hC>C-t i-terw. 


r 

TKc jusi ^alls and 

从乂七 0; beK'mdi ttc s6cr\CS iKc i-teva-tov 
匕 alls gctO oy\ Avv-ayLis-t. 



O Lefs try that on the Array too ： 

Iterator iterator = lunchMenu.createlterator(); 

while (iterator.hasNext()) { 

Menultem menultem = (Menultem)iterator.next(); 



^lo^) tWlS todt 

•,S e wbW 

sa^e as i\\t 

toAt- 


Same situation Kcvc ： {Mt 匕 lietvt jus 七 ta\\s 
KasNc^tO and ^c>c-tO; behind -tl^c sdc^cs, 
•the itev-a-tov- mdcx.cs m-to 


next() 


Array 


c 
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Meet the Iterator Patterw 


Well, it looks like our plan of encapsulating iteration just might 
actually work; and as you’ve probably already guessed, it is a 
Design Pattern called the Iterator Pattern. 

The first thing you need to know about the Iterator Pattern is 
that it relies on an interface called Iterator. Here’s one possible 
Iterator interface: 


«interface» 

Ifpratnr 


next() 



七 (） 

tells us vf avc 
move clcw»cw*ts m 
aggvcgS'bc to 'rbev-ate 
七 Wrou^v 

The y\ex.iO meihod 
vc-tuv-hs -the r\e^i 
object m the aggregate 


Now, once we have this interface, we can implement Iterators for 
any kind of collection of objects: arrays, lists, hashtables, ...pick 
your favorite collection of objects. Let’s say we wanted to 
implement the Iterator for the Array used in the DinerMenu. It 
would look like this: 


«interface» 

Ifpratnr 



next() 



DinprM^nult^r^tor 

next() 


is aw 

o( \itraior 
七 hat kyvov/s V^OY/ -bo 'rtev-ate 
ovev dn avv-37 o-f M^ultcms. 


Let’s go ahead and implement this Iterator and hook it into the 
DinerMenu to see how this works... 
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make an iterator 


Adding aw Iterator to PiwerMewu 


To add an Iterator to the DinerMenu we first need to define the 
Iterator Interface: 


public interface Iterator 
boolean hasNext(); 
Object next(); 


Hcvcs OUV two methods： 

_ The hasNe^O wtUd veW 喊 a boolean 
/ m d.6atm 3 

^ element to itev-ate ovev... 

d 心 ne ^ 0 method 
^ret^ns ih e ne ^ e | e ㈣ 士 . 


And now we need to implement a concrete Iterator that works 
for the Diner menu: 

广 - 、 

ItevaW mtev^ate. 


public class DinerMenuIterator implements Iterator { 
Menultem[] items; 

int position = 0; ^ - 


public DinerMenuIterator(Menultem[] items) { 


, w am*ka. wS 如 
\\oy\ 


Yos'»t»or\ ' 

，山 : 二 ㈣ . 


\*tcv*at'or^ < 


this.items = items; 



public Object next() { ^ 

Menultem menultem = items[position]; 
position = position + 1; 
return menultem; 



TKc dohs-tv'ud'tov- -takes -tKc 
av-vay of iiems wc arc 
jomj to i-tcvaic ovcv. 

TKc mctKod v-ctuvr\s -tKc 
itcr»» \y\ tKc avv-ay and 
m£.vcr»»cr»-ts ihc position. 


public boolean hasNext() { 


if (position >= items.length || items[position] == null) { 


return false; 
} else { 

return true; 


The has^W n.eihod chedks io 
see seer, all ihe e\e^enh 

d 七 he ayyay and veiuv-hs i^ e ^ 
iheire ave ^ore b> tieraie iKvough. 




Because -the d'mev dKe-f weivt ahead and 
allodaied a max. siz^d avvay, wc v\ccd io 
dKcdk no 七 ov\\y i-f >wc avc a-t tKc c^d o-f 
■tKc avv-ay, bu-t also i-f -tKc itcru is 
hull, vjWiCM mdi^3"tcs -tKcvc 3VC v\o move 
i'tcrus. 
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Reworking the V'mr Menu with Iterator 

Okay, we’ve got the iterator. Time to work it into the 
DinerMenu; all we need to do is add one method to create a 
DinerMenulterator and return it to the client: 


public class DinerMenu { 

static final int MAX—ITEMS = 6; 
int numberOfItems = 0; 
Menultem[] menuIterns; 


// constructor here 
// addltem here 


public Mcnultcm[] ~ getMcnuItcmci () — [■ 
return monultomo / 


IA/eVe jo'mj lo need lV>e je-t/WmllemsO 
metUd a»ymove a»d m (atl, «e <W 七 wa»l it 
because i-t c^\>oscs ouv m-tcv-r\al iw^lcrwCtvtaticm. 


如 



public Iterator createlterator() { 

return new DinerMenulterator(menultems), 

} 

// other menu methods here 


vdv-tVmj "the ("tevatov* TKc dictvt 

docs^t t\ttd "to know Kov/ »wcnu|-tcms av*c maitvtamed 


-tKc ^v-ca-tclicv-atovO mc-tKod- 
li Creates a P'mcvMchu|-tcv-a-tov 
•fv-om -tKc mchulicms av-v-ay a^d 
v-ctuv^s i-t to -tKc dierrt. 


m nov- docs it io Kow i\\t 

P'mcvMc^u|-tcva-tov is iw^lcmctvtcd. I 七 七 needs to use {\\t 

i-tevatov-s io stc^> tKv-oujK i\\t itc^s m i\\t menu. 



EweRciSie 


Go ahead and implement the PancakeHouselterator yourself and make the changes 
needed to incorporate it into the PancakeHouseMenu. 
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the waitress iterates 


Fixing up the Waitress code 

Now we need to integrate the iterator code 
into the Waitress. We should be able to get 
rid of some of the redundancy in the process. 
Integration is pretty straightforward: first we 
create a printMenuO method that takes an 
Iterator, then we use the createlteratorO method 
on each menu to retrieve the Iterator and pass it 
to the new method. 


public class Waitress { 

PancakeHouseMenu pancakeHouseMenu; 
DinerMenu dinerMenu; 



dr\d im^vovcd 

Wi-tV) IWatov. 



I 灼七 he dons-tv-ud-tov- iA/aitvcss 


r Shakes i\\t bio 




public Waitress(PancakeHouseMenu pancakeHouseMenu, DinerMenu dinerMenu) { 


this.pancakeHouseMenu = pancakeHouseMenu; 
this.dinerMenu = dinerMenu; 


public void printMenu() 



Iterator pancakelterator = pancakeHouseMenu.createlterator(); 


TVie yv-'m-tA/le«v »0 
creates 

i-tcratovs, oY\t (or 


Iterator dinerlterator = dinerMenu•createlterator(); 

System, out .println ( 、 'MENU\n - \nBREAKFAST"); 

printMenu(pancakelterator); 

System, out .println ( 、 '\nLUNCH"); 
printMenu(dinerlterator); 



f[Y\d tails 
ovev-loddcd 卜七 M ⑽ () 
cat\\ i-tev-a-tov. 


private void printMenu(Iterator iterator) 
while (iterator.hasNext()) { 

Menultem menultem 




Test i*f arc 
叫 move 'rtcw'S. 


(Menultem)iterator.next(); 七丄 
System, out .print (menultem. getName () + '、，'、）； 

System, out .print (menultem. getPrice () + '、-- '、）； 

System.out.println(menultem.getDescription()); 


// other methods here 


|s/otc v/cVc do>m 
{jo o”e loo^i 


Use 七 k io 

dr\d desdriftiow 


TKc overloaded 
pvnvtM ⑽ (） 
method uses 
i\\t Itcv-aiov- -to 

y m 七七 ^ 眯 . 
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Testing our code 

It’s time to put everything to a test. Let’s write some 
test drive code and see how the Waitress works... 


First y/e treaie ^ 


public class MenuTestDrive { / 

public static void main(String args[]) { 

PancakeHouseMenu pancakeHouseMenu = new PancakeHouseMenu(); 
DinerMenu dinerMenu = new DinerMenu(); ^ 



} 


Waitress waitress = new Waitress(pancakeHouseMenu, 
waitress.printMenu(); 



dinerMenu) ; ^ y/c trtaie a 
iVaiiv-css ar\d \>ass 

KCV* mCtMAS. 


Here's the test run... 

File Edit Window Help GreenEggs&Ham 


% java DinerMenuTestDrive 
MENU 

BREAKFAST 

K&B's Pancake Breakfast, 2 
Regular Pancake Breakfast, 
Blueberry Pancakes, 3.49 


r 


Fivs-t y/c iicv-atc 
■tKvoujK 


99 -- Pancakes with scrambled eggs, and toast 
2.99 -- Pancakes with fried eggs, sausage 
Pancakes made with fresh blueberries 
Waffles , 3.59 -- Waffles, with your choice of blueberries or strawberries 






LUNCH 

Vegetarian BLT, 2.99 -- (Fakin') Bacon with lettuce & tomato on whole wheat 
BLT, 2.99 —— Bacon with lettuce & tomato on whole wheat 


七卜 € \\Ar\t\) 
dll 

y/i-tK 七 Ke 
same 
i-tev-a-tion 
to&t- 


Soup of the day, 3.29 -- Soup of the day, with a side of potato salad 
Hotdog, 3.05 -- A hot dog, with saurkraut, relish, onions, topped with cheese 
Steamed Veggies and Brown Rice, 3.99 -- Steamed vegetables over brown rice 
Pasta, 3.89 -- Spaghetti with Marinara Sauce, and a slice of sourdough bread 


% 
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iterator advantages 


What have we done so far? 

For starters, we’ve made our Objectville cooks 
very happy. They settled their differences and 
kept their own implementations. Once we 
gave them a PancakeHouseMenuIterator and a 
DinerMenuIterator, all they had to do was add a 
createlteratorO method and they were finished. 

We’ve also helped ourselves in the process. The 
Waitress will be much easier to maintain and 
extend down the road. Let’s go through exactly 
what we did and think about the consequences: 



Hard to Maintain 
Waitress Iwpkwewfafiow 


The Menus are not well 
encapsulated; we can see the Diner 
is using an Array and the Pancake 
House an ArrayList. 

We need two loops to iterate through 
the Menultems. 


The Waitress is bound to concrete 
classes (MenultemQ and ArrayList). 


The Waitress is bound to two different 
concrete Menu classes, despite their 
interfaces being almost identical. 


New, Hip 

Waitress Powered by Iterator 


The Menu implementations are now 
encapsulated. The Waitress has 
no idea how the Menus hold their 
collection of menu items. 

All we need is a loop that 
polymorphically handles any 
collection of items as long as it 
implements Iterator. 

The Waitress now uses an interface 
(Iterator). 


The Menu interfaces are now exactly 
the same and, uh oh, we still don’t 
have a common interface, which 
means the Waitress is still bound to 
two concrete Menu classes. We'd 
better fix that. 
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What we have so far:.. 

Before we clean things up, let’s get a bird’s eye view of our current design. 


U^u. … v e — 

an d ^ ee -tv, e Wo^ a«7 

de — 一伽 一 ete ^ 


The Itcv-atov allots i\\t iVaitv-css -to be deto 呷 led 
•fv-om adiual irw^lcmc^-tation o-f tKc tomtit 
classes. SKc doesni need -to kno>w i-f a Menu is 
ir^lcmcn 七 cd y/itK an A^ay, an A'r'rayLis-t, ov with 
Postlt™ notes. All Ac ta\rcs is tKat S^c dan yi an 

I 七 evd"tov* 七 o do V^cv itc'ratmj- 


r *c rc now 



\ 



usih^ d domrvtoh 
/tcv-a-tov- 
i^tc^r-Pa^C 
v/e’ve 

i»»*plcrwCh-feccl 
"tv/o Co^c.Y'dc 
classes. 


«interface» 

Iterator 


hasNext() 

next() 






—— > 

PancakeHouseMenulterator 


DinerMenulterator 

^-i 


hasNext() 


hasNext() 



next() 


next() 







\ / 


Woie ihai -the i-teira-to*- give us a way io s-tep 
卜 u 3 h Ue eUeAJ am a^y^aie wiihoui 
+< Tf h 9^ e a 33«3 如 "t 。 tUi^ i-ts ow, 

，七 h ab^th 0 -f n.eihods io supped ivavevsal o( i^s 
elements, li also allows ihe in>plen>ehiatioh o-f ih e 
Fraley io live oubide of ihe a^aie; m oihe*- 
wolrds - weve e^apsulaied ihe i 士 vai ■ 伽 . 


p a ^o« eM -a ： dP'^ 

2 $sa：“ 
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improve the iterator 


Making some improvements... 


Okay，we know the interfaces of PancakeHouseMenu and DinerMenu are exactly the same 
and yet we haven’t defined a common interface for them. So, we’re going to do that and 
clean up the Waitress a little more. 

You may be wondering why we’re not using the Java Iterator interface - we did that so you 
could see how to build an iterator from scratch. Now that we’ve done that, we’re going to 
switch to using the Java Iterator interface, because we’ll get a lot of leverage by implementing 
that instead of our home grown Iterator interface. What kind of leverage? You’ll soon see. 

First, let’s check out the java.util.Iterator interface: 

〆 ~ N TV>*IS looks just like ouv previous ddmiW 


Exdcpt wc have ah additional meiKod that 
allows us -to remove -the las-t item vetmved by 
■the method -fv-om aggvcga'tc. 


«interface» 

Itpratnr 


next() 

removeQ 


This is going to be a piece of cake: We just need to change the interface that both 
PancakeHouseMenuIterator and DinerMenuIterator extend, right? Almost... actually, it’s 
even easier than that. Not only does java.util have its own Iterator interface, but ArrayList has 
an iteratorO method that returns an iterator. In other words, we never needed to implement 
our own iterator for ArrayList. However, we’ll still need our implementation for the 
DinerMenu because it relies on an Array, which doesn’t support the iteratorO method (or any 
other way to create an array iterator). 


What if I don’t want to provide 
the ability to remove something from the 
underlying collection of objects? 

The remove() method is considered 
optional. You don’t have to provide remove 
functionality. But, obviously you do need to 
provide the method because it’s part of the 
Iterator interface. If you’re not going to allow 
remove() in your iterator you’llwant to throw 


tl^ereiarenp 

)umb Questipns 


How does remove)) behave 
under multiple threads that may be 
using different iterators over the same 
collection of objects? 


the runtime exception 

java.Iang.UnsupportedOperationException. 
The Iterator API documentation specifies that 
this exception may be thrown from remove() 
and any client that is a good citizen will 
check for this exception when calling the 
remove() method. 


The behavior of the remove() is 
unspecified if the collection changes while 
you are iterating over it. So you should be 
careful in designing your own multithreaded 
code when accessing a collection 
concurrently. 


332 Chapter 9 




the iterator and composite patterns 


Cleaning things up withjava.otil.lterator 

Let’s start with the PancakeHouseMenu, changing it over to java.util.Iterator is 
going to be easy. We just delete the PancakeHouseMenuIterator class, add an 
import java.util.Iterator to the top of PancakeHouseMenu and change one line 
of the PancakeHouseMenu: 


public Iterator createlterator() { 

return menultems.iterator(); 

} 


l^s-tcad of dvcatmg ouv* own i-tcv*a*tov- 
how > wc just dall 七 he itcv-atov-0 method 
Oh -the Av*v-ayLis-t. 


And that’s it，PancakeHouseMenu is done. 

Now we need to make the changes to allow the DinerMenu to work with java.util.Iterator. 


import java.util.Iterator; 




public class DinerMenuIterator implements Iterator 
Menultem[] list; 
int position = 0; 


pivs 七 wc imfoirt java.u-til.l-tcv-a-tov -； -the 

m-tcir-fadc wcVc 90'mg io iw»plcmcht 


public DinerMenuIterator(Menultem[] list) { 
this.list = list; 

} 

public Object next() { 

// implementation here 

} 


public boolean hasNext() { 

// implementation here 

} 



UoYxt of OUV 


...bu-t >wc do v\ttd -to vcmovcO. 

Hcvc, bemuse -t^c is us'mj a -fix-cd 

/ siz^d v/c just sKi-ft all 

up one v-Cmovc() is tailed- 


public void remove() { 
if (position <= 0) { 

throw new IllegalStateException 

(''You can’t remove an item until you've done at least one next () ^); 

} 

if (list[position-1] != null) { 

for (int i = position-1; i < (list.length-1); i++) { 

list [i] = list[i+1]; 


list[list.length-1] = null; 
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decouple the waitress from the menus 


We are almost there... 

We just need to give the Menus a common interface and rework the Waitress 
a little. The Menu interface is quite simple: we might want to add a few more 
methods to it eventually, like addltemO, but for now we will let the chefs control 
their menus by keeping that method out of the public interface: 


public interface Menu { 

public Iterator createlterator(); 


^ This is a simple mierfau -that jUS-t 
le*ts dictvts yt ah rtevatov* -fov- 
"tKc items ih iKc mehU. 


Now we need to add an implements Menu to both the 
PancakeHouseMenu and the DinerMenu class definitions and 
update the Waitress: 


import java.util.Iterator; 


the Wai 昝 ess uses the java.wii|.|^aiov as y/ell- 


public class Waitress { 

Menu pancakeHouseMenu; 
Menu dinerMenu; 


public Waitress(Menu pancakeHouseMenu, Menu dinerMenu) 
this.pancakeHouseMenu = pancakeHouseMenu; 
this.dinerMenu = dinerMenu; 

} 


Wc heed io vcpladc iKc 
toy\C\rcic AlchU classes 
w'rtK the 


public void printMenu() { 

Iterator pancakelterator = pancakeHouseMenu•createlterator(); 
Iterator dinerlterator = dinerMenu.createlterator(); 

System.out.println (''MENU\n - \nBREAKFAST"); 

printMenu(pancakelterator); 

System, out .println ( 、 '\nLUNCH〃> ; 
printMenu(dinerlterator); 

} 

private void printMenu (工 terator iterator) { 
while (iterator.hasNext()) { 

Menultem menultem = (Menultem)iterator.next(); 

System, out .print (menultem. getName () + '、，'、）； 

System, out .print (menultem. getPrice () + '、-- '、）； y 

System.out.println(menultem.getDescription()); 


Ko-thmj dh—cs 
hcv*c. 


} 

// other methods here 
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What does this get os? 


The PancakeHouseMenu and DinerMenu classes implement an interface, 

Menu. Waitress can refer to each menu object using the interface rather than 
the concrete class. So, we 5 re reducing the dependency between the Waitress and 
the concrete classes by “programming to an interface, not an implementation.” 


TW,s solves -tV,e problem d 
■tV>e \A/ai-tv-ess deyendmoi o« 
七 V\e toUrtit Mcrxus. 


The new Menu interface has one method, createlteratorO, that is implemented 
by PancakeHouseMenu and DinerMenu. Each menu class assumes the 
responsibility of creating a concrete Iterator that is appropriate for its internal 
implementation of the menu items. 




This solves the fv-oblcm o( 
"tKc iVai-tircss dcfChdihJ ot\ 

"the 

Alchuf-tcms. 


ttcv*cs ouv new Alchu m*tcv-fadc- 
f 七 s fC^i-Pics "the hCw method ； 


^v*ca-tc|*tcva-tov* 0 . 



Koy/, WaiVcss 
or\ly v»ccds io 

be 

W\i\\ av\d 

l-tcvatovs. 


:: 二 — 





Pa.dakeHo^/VI^u a,d ,ow ^ ? ] en<en i 

t which -th ey heed io 
—erxeh 七七 he h 〜 r.eihod 



WcVc r\ovj usmj iKc /\vv-ayLisi tvca-tdicv-aiov-0 



£adh dohdvc-tc is vcspohsiblc 

•fov* dvca-tihj iKc appvopv-ia*tc 


iieva-tov sullied by java uiil. 
Wt need tKis a^ymovc. 



method bcd^usc 
i\\t kmd i 七 evaiov 

yc^uivcd "to itcv'a'tc 
over i-ts ^v-v-ay o( 
r»»cr\u i-tows. 


tOY\tYt{.t l-tcvatov- dldss. 
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iterator pattern defined 


Iterator Pattern defined 


You’ve already seen how to implement the Iterator 
Pattern with your very own iterator. You’ve also seen 
how Java supports iterators in some of its collection 
oriented classes (the ArrayList). Now it’s time to check 
out the official definition of the pattern: 


The Iterator Pattern provides a way to 
access the elements of an aggregate object 
sequentially without exposing its underlying 
representation. 


This makes a lot of sense: the pattern gives you a way 
to step through the elements of an aggregate without 
having to know how things are represented under the 
covers. You’ve seen that with the two implementations 
of Menus. But the effect of using iterators in your 
design is just as important: once you have a uniform way 
of accessing the elements of all your aggregate objects, 
you can write polymorphic code that works with any 
of these aggregates — just like the printMenuO method, 
which doesn’t care if the menu items are held in an 
Array or ArrayList (or anything else that can create an 
Iterator), as long as it can get hold of an Iterator. 

The other important impact on your design is that the 
Iterator Pattern takes the responsibility of traversing 
elements and gives that responsibility to the iterator 
object, not the aggregate object. This not only keeps 
the aggregate interface and implementation simpler, 
it removes the responsibility for iteration from the 
aggregate and keeps the aggregate focused on the 
things it should be focused on (managing a collection of 
objects), not on iteration. 

Let’s check out the class diagram to put all the pieces in 
context... 


Tke Iterator Pattern allows 
traversal ojf tke elements 
ojf an aggregate witkout 
exposing tke uncterlyingf 
implementation. 

It also places tke task ol 
traversal on tke iterator 
object, not on tke aggregate, 
vkick simplifies tke 
aggregate interface anti 
implementation, anct places 
tke responsibility wkere it 
skould lie. 
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Havi% a dommoh m-tcv-fadc -for youv 
aggircja-tcs is Kandy (&r vouv died; 
it decouples yowr dlicrrt Wo^ the 
i^flcmch-ta-tioh youv- dollc^ioh o( objects. 



TKc Itcv-a-tov- mtev-fade 
^v-ovidcs 七 he mtev-fade 
■Ua 七 all i-tev-atov-s 
must implc»wCtvt，and 
a set o-f rwet^ods 






The class diagram for the Iterator Pattern looks very similar to another Pattern you’ve studied; can you 
think of what it is? Hint: A subclass decides which object to create. 
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q&a about iterator 


DumPc^uestiPiis 


I’ve seen other books show the 
Iterator class diagram with the methods 
first(), next(), isDone() and currentltem(). 
Why are these methods different? 

Those are the “classic” method 
names that have been used. These names 
have changed over time and we now have 
next(), hasNext() and even remove() in 
java.util.lterator. 

Let’s look at the classic methods. The 
next() and currentltem() have been merged 
into one method in java.util. The isDone() 
method has obviously become hasNext(); 
but we have no method corresponding to 
first(). That’s because in Java we tend to 
just get a new iterator whenever we need to 
start the traversal over. Nevertheless, you 
can see there is very little difference in these 
interfaces. In fact, there is a whole range 
of behaviors you can give your iterators. 

The remove() method is an example of an 
extension in java.util.lterator. 

I’ve heard about “internal” 
iterators and “external” iterators. What 
are they? Which kind did we implement 
in the example? 

We implemented an external iterator, 
which means that the client controls the 
iteration by calling next() to get the next 
element. An internal iterator is controlled 
by the iterator itself. In that case, because 
it’s the iterator that’s stepping through the 
elements, you have to tell the iterator what 
to do with those elements as it goes through 
them. That means you need a way to pass 
an operation to an iterator. Internal iterators 
are less flexible that external iterators 
because the client doesn’t have control of 
the iteration. However, some might argue 


that they are easier to use because you just 
hand them an operation and tell them to 
iterate, and they do all the work for you. 

Could I implement an Iterator that 
can go backwards as well as forwards? 

Definitely. In that case, you’d 
probably want to add two methods, one to 
get to the previous element, and one to tell 
you when you’re at the beginning of the 
collection of elements. Java’s Collection 
Framework provides another type of iterator 
interface called Listlterator. This iterator 
adds previous。and a few other methods 
to the standard Iterator interface. It is 
supported by any Collection that implements 
the List interface. 

Who defines the ordering of the 
iteration in a collection like Hashtable, 
which are inherently unordered? 

Iterators imply no ordering. The 
underlying collections may be unordered as 
in a hashtable or in a bag; they may even 
contain duplicates. So ordering is related 
to both the properties of the underlying 
collection and to the implementation. In 
general, you should make no assumptions 
about ordering unless the Collection 
documentation indicates otherwise. 

You said we can write 
“polymorphic code” using an iterator; 
can you explain that more? 

When we write methods that take 
Iterators as parameters, we are using 
polymorphic iteration. That means we are 
creating code that can iterate over any 


collection as long as it supports Iterator. 

We don’t care about how the collection 
is implemented, we can still write code to 
iterate over it. 

If I’m using Java, won’t I always 
want to use the java.util.lterator 
interface so I can use my own iterator 
implementations with classes that are 
already using the Java iterators? 

Probably. If you have a common 
Iterator interface, it will certainly make it 
easier for you to mix and match your own 
aggregates with Java aggregates like 
ArrayList and Vector. But remember, if you 
need to add functionality to your Iterator 
interface for your aggregates, you can 
always extend the Iterator interface. 

I’ve seen an Enumeration 
interface in Java; does that implement 
the Iterator Pattern? 

We talked about this in the Adapter 
Chapter. Remember? The java.util. 
Enumeration is an older implementation 
of Iterator that has since been replaced 
by java.util.lterator. Enumeration has 
two methods, hasMoreElements(), 
corresponding to hasNext(), and 
nextElement(), corresponding to next(). 
However, you’ll probably want to use Iterator 
over Enumeration as more Java classes 
support it. If you need to convert from one 
to another, review the Adapter Chapter 
again where you implemented the adapter 
for Enumeration and Iterator. 
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Single Responsibility 

What if we allowed our aggregates to 
implement their internal collections and 
related operations AND the iteration 
methods? Well, we already know that 
would expand the number of methods in 
the aggregate, but so what? Why is that 
so bad? 


Well, to see why, you first need to recognize that when we allow 
a class to not only take care of its own business (managing 
some kind of aggregate) but also take on more responsibilities 
(like iteration) then we’ve given the class two reasons to change. 
Two? Yup, two: it can change if the collection changes in 
some way, and it can change if the way we iterate changes. So 
once again our friend CHANGE is at the center of another 
design principle: 



We know we want to avoid change in a class like the plague 
一 modifying code provides all sorts of opportunities for 
problems to creep in. Having two ways to change increases 
the probability the class will change in the future, and when 
it does, it’s going to affect two aspects of your design. 

The solution? The principle guides us to assign each 
responsibility to one class, and only one class. 

That’s right, it’s as easy as that, and then again it’s not: 
separating responsibility in design is one of the most 
difficult things to do. Our brains are just too good at seeing 
a set of behaviors and grouping them together even when 
there are actually two or more responsibilities. The only 
way to succeed is to be diligent in examining your designs 
and to watch out for signals that a class is changing in more 
than one way as your system grows. 


Every responsibility of a 
class is an area of potential 
ckangfe. More tkan one 
responsibility means more 
tkan one area ojf ckange. 


Tkis principle guides us to 
keep eack class to a single 
responsibility. 


Cohesion is a term you’ll 
hear used as a measure of 
〜 . how closely a class or a 

module supports a single 
■plllll \ purpose or responsibility. 

」 We say that a module or 
class has high cohesion 
when it is designed around a set of 
related functions, and we say it has low 
cohesion when it is designed around a 
set of unrelated functions. 


Cohesion is a more general concept 
than the Single Responsibility Principle, 
but the two are closely related. 

Classes that adhere to the principle 
tend to have high cohesion and are 
more maintainable than classes that 
take on multiple responsibilities and 
have low cohesion. 
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multiple responsibilities 





Examine these classes and determine which ones have multiple responsibilities. 



Person 



setName() 

setAddress() 


Game 



Phone 

login() 



dial() 

setPhoneNumber() 

signupO 


save() 


hangUp() 

move() 


load() 


talk() 

fire() 



sendData() 

rest() 




flash() 


I 




GumballMachine 


getCount() 

getState() 

getLocation() 


Iterator 


DeckOfCards 


hasNext() 

next() 

remove() 

addCard() 

removeCard() 

shuffle() 


ShoppingCart 


add() 

remove() 

checkOut() 

saveForLater() 


hasNext() 

next() 

removeQ 


% 


HARD HAT AREA, WATCH OUT 
FOR FALLING ASSUMPTIONS 




Determine if these classes have low or high cohesion. 


Game 


login() 


signup() 


move() 


fire() 


rest() 


getHighScore() 


getName() 



PlayerActions 


GameSession 


login() 

signupQ 



Player 


getHighScore() 

getName() 
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a new menu 


Taking a look at the Cafe Menu 


Here’s the Cafe Menu. It doesn’t look like too much trouble to integrate the 
Cafe Menu into our framework... let’s check it out. 




public class CafeMenu { 
Hashtable menultems 






new Hashtable(), 




} 


public CafeMenu() { 

addltem(''Veggie Burger and Air Fries", 
''Veggie burger on a whole wheat bun. 


Like otV.ev Mer-us, -the itew a 代 

\C ^ mitial.«d m the 6o«stvu6W 

lettuce, tomato, and fries 〃， 


true, 3.99); 

addltem (''Soup of the day ”， 

''A cup of the soup of the day, with a side salad", 
false, 3.69); 
addltem (''Burrito ’’， 

''A large burrito, with whole pinto beans, salsa, guacamole", 
true, 4.29); 


public 


void addltem(String name, String 
boolean vegetarian, 


^ttcvcs 

description, a^d add »*t io ^as^tablc. 

double price) 


{ 


Menultem menultem = new MenuItem(name, description, vegetarian, price); 
menultems.put(menultem.getName(), menultem); 

ihe ke y is th e 乂心 value is ^ wult 加 objedi 

public Hashtable getltems() { 


return menultems; 



WeVe noi io Uis 3n y^ e . 


^Sharpen your pencil 

Rfifnm Innkir 


Before looking at the next page, quickly jot down the three things 
we have to do to this code to fit it into our framework: 


2 -. 
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Reworking the Cafe Menu code 


Integrating the Cafe Menu into our framework is easy. Why? Because 
Hashtable is one of those Java collections that supports Iterator. But it’s not 
quite the same as ArrayList... 



Ca-fcMcnu Menu 

•m 七乙 c, so ttc l/Vaitv-css tar\ use 


public class CafeMenu implements Menu { 
Hashtable menuIterns = new Hashtable(), 

public CafeMenu() { 

// constructor code here 

} 


i-t jus-t like o-tV^cv- ty/o Menus. 


1/VcVc us'm^ ttasK-tablc bc“usc it、a 
dommon da-ba s-tv-udWc (or s-tov-'mg values ； 


public void addltem(String name. String description, 

boolean vegetarian, double price) 

{ 

Menultem menultem = new MenuItem(name, description, vegetarian, price); 
menultems.put(menultem.getName(), menultem); 


public Haohtablc gctltcmoO 
return monultoms; 




public Iterator createlterator () { ~^ s v/c drcatcl"tcv-3't<>v'^ 

return menultems•values().iterator(); method. Notice 七 ha 七 y/cVc r\oi jctt'mg an Itcv-atov- 
} ^ 矸 ashlabk jus-t (or values. 


Cl^se 


Hashtable is a little more complex than the ArrayList because it 
supports both keys and values, but we can still get an Iterator 
for the values (which are the Menultems). 


public Iterator createlterator() { 

return menultems.values().iterator(); 


} 

Fivs-t jet *tV\c values o( ttc Hashtable, 
y/KidK is jus-t a dollcttion o( all 
objcd*ts K 3 s^"t 3 blc- 




kkily that “lid support ihc 
^od, Whidh *-eW«s a 
°^ eti ° + ^ypejava.utiM^^. 
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test drive the new menu 


Adding the Cafe Mewo to the Waitress 


That was easy; how about modifying the Waitress to support our new Menu? 
Now that the Waitress expects Iterators, that should be easy too. 


The Ca-fc menu is passed mto -tKc IA/aitvcss m 
■the dons-tvud-tov WitK tKc otKcv menus, and 
s*tdsK i*t variable. 

public Waitress(Menu pancakeHouseMenu, Menu dinerMenu, Menu cafeMenu) { 
this.pancakeHouseMenu = pancakeHouseMenu; 
this.dinerMenu = dinerMenu; 
this.cafeMenu = cafeMenu; 



public class Waitress { 
Menu pancakeHouseMenu 
Menu dinerMenu; 

Menu cafeMenu; 




public void printMenu() { 


Iterator pancakelterator = pancakeHouseMenu.createlterator(); 


Iterator dinerlterator = dinerMenu•createlterator(); 
Iterator cafelterator = cafeMenu • createlterator () ,• 

System.out.println ( 、 'MENU\n - \nBREAKFAST">; 

printMenu(pancakelterator); 

System.out.println (' 、 \nLUNCH"); 
printMenu(dinerlterator); 

System, out.println ( 、 '\nDINNER") ; ^ - - - 

printMenu(cafelterator); 



Wtrt usmj -tKc Ca-fcs 

-fov ouv dinner me 灼 u. 
All Kavc -to do io 
i-t is dvcaic iKc i-tevaiov, 

^>ass i-t -to pvitvt/VIe 灼 uO. 

TKa^s i*t| 


private void printMenu(Iterator iterator) { 
while (iterator.hasNext()) { 

Menultem menultem = (Menultem)iterator.next(); 
System, out .print (menultem. getName () + '、，'、）； 
System, out .print (menultem. getPrice () + '、-- '、）； 
System.out.println(menultem.getDescription()); 

} 
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Preakfast lunch ANI? dinner 


Let’s update our test drive to make sure this all works. 


public class MenuTestDrive { 

public static void main(String args[]) { 

PancakeHouseMenu pancakeHouseMenu = new PancakeHouseMenu(); 
DinerMenu dinerMenu = new DinerMenu(); 

CafeMenu cafeMenu = new CafeMenu(); 


Cvcaic a CafeMenu … 


... and \>ass it to Wi-tv-css. 

Waitress waitress = new Waitress(pancakeHouseMenu, dinerMenu, cafeMenu); ^ - ^ 

waitress.printMenu(); 


Now, wheK, pirihi W« should see all ^v-ee 


Here^ the test run; check oot the new dinner menu from the Cafe! 


File Edit Window Help Kathy&BertLikePancakes 


% java DinerMenuTestDrive 


r 


Fivsi wc itcv-atc 
-tKv-oujK 


• the drncv- 


BREAKFAST ^ 

K&B's Pancake Breakfast, 2.99 -- Pancakes with scrambled eggs, and toast 
Regular Pancake Breakfast, 2.99 -- Pancakes with fried eggs, sausage 
Blueberry Pancakes, 3.49 -- Pancakes made with fresh blueberries a ,,. 

Waffles, 3.59 -- Waffles, with your choice of blueberries or strawberries ^ 

广 {Mt d'mcv* 

LUNCH ^ menu. 

Vegetarian BLT, 2.99 -- (Fakin') Bacon with lettuce & tomato on whole wheat 

BLT, 2.99 -- Bacon with lettuce & tomato on whole wheat 

Soup of the day, 3.29 -- Soup of the day, with a side of potato salad 

Hotdog, 3.05 -- A hot dog, with saurkraut, relish, onions, topped with cheese 

Steamed Veggies and Brown Rice, 3.99 -- Steamed vegetables over brown rice 

Pasta, 3.89 -- Spaghetti with Marinara Sauce, and a slice of sourdough bread 

dinner dT'N/Wl -finally the 

Soup of the day, 3.69 -- A cup of the soup of the day, with a side salad 
Burrito, 4.29 -- A large burrito, with whole pinto beans, salsa, guacamole a || ' 

Veggie Burger and Air Fries, 3.99 -- Veggie burger on a whole wheat bun, . 

lettuce, tomato, and fries same i eva \ov\ 

% 匕 ode. 
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what did we do? 




go y/c ^ave iKc l/Vaiivcss an 
I'tcv'atov* -fov cadK kind o-f 
gvou^ o( objects sKc needed 
to iteva 七 c ovcv … 、 


She’s bcch dedou^led -fv-om -the implcr»»cr\-ta-tioh. 
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and we made the Waitress more extensible 



By giving hcv an Itcv-a-tov- 
y/e Kave dcdou^lcd \\tr -fv-om 
iKc implementation o( 

i-tems, so v/C C3sily 
add Menus i-f y/c >want 


r 

Hashtable 


m 

_ 

A 


-next(). 


be£ause ea, we ihe 

^ iWte 。夕 
SL7l obje£h - ^ 

，★起 “也 |s 


Q~~ 


\/^t easily added 

arvot^cv- 

(Jc mer\u i-tc^s, a^d 
s'mtc Vic provided drv 

IWa 七 or, 七 ^ Waitress 
|cr\C>fi y/V>a 七 " to do’ 


exposed. 


/ /Wak'mg ah /-tcv-a-tov- 

( ^ -t^c Hash-table 

) values was casy; wKeh 

you 匕 all 

valucs.'rfec»ra-tov-0 
y° u sc-fe ah 

lievaiov. 


Put there's more! 

Java 3'ivcs you a lo-t O-P 
\ollcd ： ioh" dlasscs -tKa-t allow 
y ou "t° s-torc ahd vetvieve 
Stroups O-P obje^-ts. Fov- cample, 
\/cd-toir ahd LihkedLisi *• - 

Q 、 

Most have di-f-fcvc^-t 
'm-tcv--fad.cs. 


LihkedList 


Vector 


B»u-t almost all 
払 en> sw?? 0 ^ a 
wa7 七 0 obta'm ar' 
1 -tcv-aW- v 


Q,Q,Q,Q 

、 12 3 4 


A^d i-f they do /七 support 
Itcv-a-tov-, tKaVs ok, bedause now 
you khow Kow -to build youv ovm. 



id worc\ 
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Iterators and Collections 


We’ve been using a couple of classes that are part of the Java Collections Framework. 
This “framework” is just a set of classes and interfaces, including Array List，which we’ve 
been using, and many others like Vector, LinkedList, Stack, and Priority Queue. Each 
of these classes implements the java.util.Collection interface, which contains a bunch of 
useful methods for manipulating groups of objects. 

Let’s take a quick look at the interface: 



«interface» 

Collection 


add() 
addAllf) 
clear() 
contains() 
containsAII() 
equals() 
hashCode() 
isEmpty() 
iterator() 
remove() 
removeAII() 
retainAllf) 
size() 
toArrayQ 


. As 70 ut a, See ,W S all^s^ ood 


our old -fvicnd, i"tcv*a*tov*0 
method. Wi-tK tv>is method, you t^v\ get 
av\ Itcva-tor (or any dass 七 h 七 
Colledticm 


°^ t]r hahd y ^ods ihdludc si“0, 

to sci iKc hur»»bc<r o( clevis, 
ahd 铋 “ yO to Wh y 财 
to\\tthoY\ ihto an av-vay. 


The nice thing about Collections and 
Iterator is that each Collection object 
knows how to create its own Iterator. 
Calling iterator() on an ArrayList returns a 
concrete Iterator made for Array Lists, but 
you never need to see or worry about the 
concrete class it uses; you just use the 
Iterator interface. 



Hashtable is one of a few 
classes that indirectly 
supports Iterator. As you saw 
when we implemented the 
CafeMenu, you could get an 
Iterator from it, but only by 
first retrieving its Collection 
called values. If you think 
about it, this makes sense: 
the Hashtable holds two 
sets of objects: keys and 
values. If we want to iterate 
over its values, we first need 
to retrieve them from the 
Hashtable, and then obtain 
the iterator. 
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Iterators awd Collections 
iw Java 5 


Java 5 includes a new form of the for statement, called 
for/in, that lets you iterate over a collection or an array 
without creating an iterator explicitly. 

To use for/in, you use a for statement that looks like: 


licvaics ovcv 
eafih objcd-t m 
"the ^ollc^tioh. 


\ 


obj is assigned to i\\t ” e 乂七 
m i\\C toWtthor^ 
tat\\ twe i\\t loor 


for (Object obj : collection) { 



Here’s how you iterate over an ArrayList using for/in: 


Load up av\ 

Av'v-ayLis-t o( 
^lcy\uHcn\s. 


ArrayList items = new ArrayList(); 
items . add (new Menultem (''Pancakes", ''delicious pancakes’’ ， true, 1.59); 
items . add (new Menu Item (''Waffles^, ''yummy waffles", true, 1.99); 
items . add (new Menultem (''Toast", ''perfect toast", true, 0.59); 



for (Menultem item: items) { 

System, out .printIn (''Breakfast item: 

} 


item), 




licvaic ovcv -the lis-t a^d pv-m-t 
cadh i-tem. 



You need to use Java 5’s new 
generics feature to ensure for/ 
in type safety. Make sure you 
read up on the details before 
using generics and for/in. 
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code magnets 



Code Magnets 

The Chefs have decided that they want to be able to alternate their lunch menu items; in other words, 
they will offer some items on Monday, Wednesday, Friday and Sunday, and other items on Tuesday, 
Thursday, and Saturday. Someone already wrote the code for a new"Altemating〃DinerMenu Iterator 
so that it alternates the menu items, but they scrambled it up and put it on the fridge in the Diner as a 
joke. Can you put it back together? Some of the curly braces fell on the floor and they were too small 
to pick up, so feel free to add as many of those as you need. 


Menultem menultem = 

items[position]; 

position = position 

+ 2; 

return menultem; 



import java.util.Iterator; 
import java. util.Calendar; 


0 


I public AlternatingDinerMenuIterator (Menultem^tems^ 

this.items = items; 

Calendar rightNow = Calendar.getlnstance(); 

£^j^ ion = rightNow. get (Calendar. DAY OF WEEK) % 2; 


public void remove() { 




Menultem[] items; 
int position; 


□ 


public class AlternatingDinerMenuIterator 


public boolean hasNext() { 



throw new UnsupportedOperationException( 

''Alternating Diner Menu Iterator does not support remove ()"); 

if (position >= items.length || items[position] == nu 丄丄 ） t 
return false; 

} else { 

return true; 

} _ 

b 
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Is the Waitress ready for prime time? 

The Waitress has come a long way, but you’ve gotta admit 
those three calls to printMenuO are looking kind of ugly. 

Let’s be real, every time we add a new menu we are going to 
have to open up the Waitress implementation and add more 
code. Can you say “violating the Open Closed Principle?” 


Thiree ^eaielieyaio\-0 calls. 

ic void printMenu() { 

Iterator pancakelterator = pancakeHouseMenu.createlterator(); 

Iterator dinerlterator = dinerMenu•createlterator(); 

Iterator cafelterator = cafeMenu.createlterator(); 

System, out • println ( 、 'MENU\n - \nBREAKFAST"); 

printMenu(pancakelterator); 

System.out.println (' 、 \nLUNCH 〃）； 
printMenu(dinerlterator); 

System, out .println ( 、 '\nDINNER"); 
printMenu(cafelterator); 

夕 , 

Evcv-yiimc wc add or remove d y/cVc jomj 

{jo Kavc -to this to&t -for 

It’s not the Waitress’ fault. We have done a great job of decoupling the menu implementation and 
extracting the iteration into an iterator. But we still are handling the menus with separate, independent 
objects — we need a way to manage them together. 




TWcc tails -to 饮 u. 





The Waitress still needs to make three calls to printMenuQ, one for each menu. Can you think of a 
way to combine the menus so that only one call needs to be made? Or perhaps so that one Iterator is 
passed to the Waitress to iterate over all the menus? 
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a new design? 


This isn't so bad, all we 
need to do is package 
the menus up into an ArrayList 
and then get its iterator to iterate 
through each Menu. The code in the 
Waitress is going to be simple 
and it will handle any number of 
menus. 


Sounds like the chef is on to something. Let’s give it a try: 





public class Waitress { 

ArrayList menus; 

public Waitress(ArrayList menus) { 
this.menus = menus; 



Now wc jus-t "take an 
Av*v-ayLis-t o-f 


public void printMenu() { 

Iterator menulterator = menus.iterator(); 
while(menulterator.hasNext()) { 

Menu menu = (Menu)menulterator.next(); 
printMenu(menu.createlterator()); 



wc i-tcv-atc 
•tKvoujK -the 
rwc^us, |>assihj 
i-teva-tov- 

io the ovcv-loadcd 
pv-ih-tMchuO method. 


void printMenu(Iterator iterator) { 
while (iterator.hasNext()) { 

Menultem menultem = (Menultem)iterator.next(); 
System, out .print (menultem. getName () + 、、， 、、）； 
System, out .print (menultem. getPrice () + 、、 --、、）； 
System.out.println(menultem.getDescription()); 

} 



Ko todt 


This looks pretty good, although we’ve lost the names of the menus, 
but we could add the names to each menu. 
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Just whew we thought it was safe... 



少' 


We can’t assign a dessert menu to 
a Menultem array. 


Time for a change! 
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time to refactor 


What do we weed? 


The time has come to make an executive decision to 
rework the chef’s implementation into something that 
is general enough to work over all the menus (and 
now sub menus). That’s right, we’re going to tell the 
chefs that the time as come for us to reimplement their 
menus. 

The reality is that we’ve reached a level of complexity 
such that if we don’t rework the design now, we’re 
never going to have a design that can accommodate 
further acquisitions or submenus. 

So, what is it we really need out of our new design? 

■ We need some kind of a tree shaped structure that 
will accommodate menus, submenus and menu 
items. 


We need to make sure we maintain a way to 
traverse the items in each menu that is at least 
as convenient as what we are doing now with 
iterators. 


We may need to be able to traverse the items in 
a more flexible manner. For instance, we might 
need to iterate over only the Diner’s dessert menu, 
or we might need to iterate over the Diner’s entire 
menu, including the dessert submenu. 
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Betause we r^teA io 代? 代 sc » '七 
sub and 

: 二 : 二十 f 以 

m a tv«-V.k c 


Q 


' Q 1 

/l\ 

Q Q Q 



V\/c need *to 
a66omoda*tc M 





IA/ e st.ll io be able 
七。 -tvavcvse ^ll 如 "^ 
in -t^e tv-ee- 



Q 

^ ... ^Y\d sub maus... / V \ 

\ / ... 

^ w N A /7 ^ 

o o o o ':上么- 


★ e 。咖。时」 . 






How would you handle this new wrinkle to our design requirements? Think about it before turning the page. 
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composite pattern defined 


The Composite Patterw defined 


That’s right, we’re going to introduce another pattern 
to solve this problem. We didn’t give up on Iterator - it 
will still be part of our solution - however, the problem 
of managing menus has taken on a new dimension that 
Iterator doesn’t solve. So, we’re going to step back and 
solve it with the Composite Pattern. 

We’re not going to beat around the bush on this pattern, 
we’re going to go ahead and roll out the official definition 
now: 


The Composite Pattern allows you to 
compose objects into tree structures to 
represent part-whole hierarchies. Composite 
lets clients treat individual objects and 
compositions of objects uniformly. 




tWild clcwcrx-ts 

arc called 於 odes. 


Afede- 



Lec^ 


y/i-t^ou-t ^ildvcr» 
av-c called leaves. 



Let’s think about this in terms of our menus: this pattern 
gives us a way to create a tree structure that can handle 
a nested group of menus and menu items in the same 
structure. By putting menus and items in the same 
structure we create a part-whole hierarchy; that is, a tree of 
objects that is made of parts (menus and menu items) but 
that can be treated as a whole, like one big iiber menu. 


Once we have our iiber menu, we can use this pattern 
to treat “individual objects and compositions uniformly.” 
What does that mean? It means if we have a tree structure 
of menus, submenus, and perhaps subsubmenus along with 
menu items, then any menu is a “composition” because 
it can contain both other menus and menu items. The 
individual objects are just the menu items - they don’t hold 
other objects. As you’ll see, using a design that follows the 
Composite Pattern is going to allow us to write some simple 
code that can apply the same operation (like printing!) over 
the entire menu structure. 




\xtt stv-udWc- 


o 




av-C 


dies a^d 


arc leaves. 
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㈨ e ta« freale arbiW— 
tom'plc% VCCS. 广 


/l\ 




八 \ 
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1 ^?W 

Mc^uiw O O OiC3 
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•ov as |>avts. 


0 ;;lSO. ” 上 ° 


Tke Composite Pattern 
allows us to l>uilct structures 
of objects in tke ■form of 
trees tkat contain Lotk 
compositions of objects and 
indivictual objects as nodes. 

Using a composite structure, 


same 


we can apply tke same 
operations over Lotk 
composites and indivictual 
objects. In otker words, in 
most cases we can ignore 
tke differences between 
compositions of objects anct 
indivictual objects. 




Qf © Sw T 2 

Q Q U U Q 


Qri^ ^ 
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composite pattern class diagram 


The CU « es 十丄 

C.ow^os»t»o\r\- 


Client 


^ ihH ih e Leaf a|so 
' hheHis n ^ods like addO, 
= ve ° — 3 必 ild(UWh 

do ^ ^ a ]oi 
sehse ^ a lea+ hode. W e V e 
9 oi »9 io £o«, e back io -this i SS(<e . 

A Leaf has i 

^Kild^rch. 


t 0 — 桠 一一 “也 


T ^l ^ i-pU 山 

9 i^ 


J 



/ 

A L~cb-( dc-Pihcs "tKc bcKdviov* -Pov *tKc 
clcrwctr»*ts ih 七 he dorwposi-tioh- ("t docs 
"this by implcmetvtmg the opevatiohs 
"the Composite suppovb- 


Composite 

add(Component) 

remove(Component) 

getChild(int) 

operation() 


T 


Ty^c Com^osi-tc S role IS -to dc*f'mc 
bc^av'iov dor»»^or\Cr\'ts 

havmg 乩 ildbr 饮 a”dl "io s-torc t\\M 
dor»\^or\C^*ts- 


Co XtJ^ 

I s 


r^cc 


■ated- 


Component, Composite, Trees? 
I’m confused. 

A composite contains components. 
Components come in two flavors: 
composites and leaf elements. Sound 
recursive? It is. A composite holds a set 
of children, those children may be other 
composites or leaf elements. 


Dtml 


i©stipns 


When you organize data in this way you end 
up with a tree structure (actually an upside 
down tree structure) with a composite at the 
root and branches of composites growing up 
to leaf nodes. 




How does this relate to iterators? 


Remember, we're taking a new 
approach. We’re going to re-implement the 
menus with a new solution: the Composite 
Pattern. So don’t look for some magical 
transformation from an iterator to a 
composite. That said, the two work very 
nicely together. You’ll soon see that we 
can use iterators in a couple of ways in the 
composite implementation. 
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the iterator and composite patterns 

Pesigning Menus with Composite 

So, how do we apply the Composite Pattern to our menus? To start with, we need to create a 
component interface; this acts as the common interface for both menus and menu items and allows 
us to treat them uniformly. In other words we can call the same method on menus or menu items. 

Now, it may not make sense to call some of the methods on a menu item or a menu, but we can deal 
with that, and we will in just a moment. But for now, let’s take a look at a sketch of how the menus 
are going to fit into a Composite Pattern structure: 


,to use -tVe 




/WchuCompohCht v-cpvcschts the (or 

both McK>u|-tcr»» a^d Mck^u. used By\ abs-tv-ad-t 
dass Kcvc bcdausc v/c 七。 pv-ovidc dc-faul-t 
impIcmCh-tatiohS -fov- these methods. 



tteve av-c rwctKods -for 〆 

TKc dor»\^onCn"ts a\rc 
yV|c^u|-tcr»» Menu. 


MenuComponent 

getName() 

getDescription() 

getPrice() 

isVegetarian() 

print() 

add(Component) 

remove(Component) 

getChild(int) 


Boih /Wchu/i Cm ahC ( /V) ChUS 

術 hdc 卜 iO. 


getName() 

getDescription() 

getPrice() 

isVegetarian() 

print() 


刈 ⑽ l ov e ^ ， d« £ he ihai nake 

咖 e, a»d «« £he drkli .,,, 

D , r e d f au，t "*'Ple«'e»£a£io« s ih 

•u<^ ponen “ ov _ 妯咐 

s c^c (like addO - a ^ ^ , 

add a / / , d h 1 ^ ke io 

T. a ioa /^ en uli ern ... we £ah o ， v 

add £o«,p 0 nehis io a /Vj ehU ). y 


menuComponents 

getName() 

getDescription() 

print() 

add(Component) 

remove(Component) 

getChild(int) 


]^/c KdVC S 0 nr»C o( 
same methods you 11 
v-cmcmbcv- -fv-ow ouv- 
^revious vevsio^s of 
and Mcr»u, 

and 破 、 t added \>vnvt(), 
addO, vcmovcO 3 r\d 
jc-tCWildO. Well describe 
■tV^csc soor\, y/ViC^ v/c 
iw^lcmcivt ouv Y\t^i Menu 
dr\d Mcr»u|-tcm classes. 




M e «u also ov e „id e s tv« e 

se « se , l^a^avtoadda^ «-v e 一、 W 

|« addition ^ell ^ 5 etNa» e O arvd 
♦ 岣 W() to 代 W“V>e 一 

and destv-?tio« "'⑽ . 
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implementing composite mem/s 


Implementing the Menu Component 

Okay ， we’re going to start with the 
MenuComponent abstract class; remember, the 
role of the menu component is to provide an 
interface for the leaf nodes and the composite 
nodes. Now you might be asking, “Isn’t the 
MenuComponent playing two roles?” It might 
well be and we’ll come back to that point. 

However, for now we’re going to provide a default 
implementation of the methods so that if the 
Menultem (the leaf) or the Menu (the composite) 
doesn’t want to implement some of the methods 
(like getChildO for a leaf node) they can fall back 
on some basic behavior: 


Mer>uCom ? orver,t provides default 

public abstract class MenuComponent { 

public void add(MenuComponent menuComponent) { 
throw new UnsupportedOperationException(); 

} 

public void remove(MenuComponent menuComponent) 
throw new UnsupportedOperationException(); 

} 

public MenuComponent getChild(int i) { 

throw new UnsupportedOperationException(); 


All components must implement 
the MenuComponent interface; 
however, because leaves and 
nodes have different roles we 
can’t always define a default 
implementation for each 
method that makes sense. 
Sometimes the best you can do 
is throw a runtime exception. 


Because some o( tKcsc methods ohly make 
(or /Vlchulicms, ar\d some ohly make sertse (or 
A^lchus, iKc de-Faul-fc implemeh-taiioh is 



Uhsu^ov-tcdOfcv-a-tiohE^cfiio^. That v/ay ； 
i-f Mcr»u|-tcm oy doesn't support By\ 
opev-a-tioh, they doht Have -to do 
"tKcy jus-t ihhevi 七 -fcKe 
de-Faul-fc 七 ioh . 

, 

V Wc vc grouped -togc-thcv- -the 
u domposi-tc w methods - -tha-t is, 
rwctKods *to Sdd, VCrwovC 3hd yt 
AlchuComponCh'ts- 


public String 
throw new 

} 

public String 
throw new 

} 

public double 
throw new 

} 

public boolean isVegetarian() { 

throw new UnsupportedOperationException() 

} 


getName() { 

UnsupportedOperationException(); 

getDescription() { 

UnsupportedOperationException(); 

getPrice() { 

UnsupportedOperationException(); 


public void print() { 

throw new UnsupportedOperationException(); 




Heve ave lV>e “外的如。/ metiiods; 
these a« ^ W tV,e U 七 ⑽. 
|*t ^ a ^ so USC a 

tou ? lc m too, as 

youll see rn a tousle ok ?ays ▲ 
vjc sV^ov/ Me ⑽ todt. 



fvihiO is an w opcratioh w method 
that both ouv /Wc^us ahd /^lcr\ulicms 
v/ill irwplemeirt, but wc pVovidc 3 
dc-fau|-t opev-a-tioh Kcvc. 
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the iterator and composite patterns 


Implementing the Menu Item 

Okay, let’s give the Menultem class a shot. Remember, 
this is the leaf class in the Composite diagram and it 
implements the behavior of the elements of the composite. 


public class Menultem extends MenuComponent { 


String name; 

String description; 
boolean vegetarian; 




double price; 


public Menultem(String name. 

String description, 
boolean vegetarian, 
double price) 

{ 

this.name = name; 



I’m glad we're going in 
this direction. I'm thinking this is 
going to give me the flexibility I need 
to implement that crepe menu I’ve 
always wanted. 




wc need io 

TKc to^s-tv-ud-tov* jus 七 -takes 

iKc name, des 乙 tkt- 

a -to iKcm all- 

TKis is 七切 r^udK like our old 
i-tem impIcw'Cn'tol'tioh- 



this.description = description; 
this.vegetarian = vegetarian; 
this.price = price; 


public String getName() { 
return name; 


public String getDescription() 
return description; 

} 

public double getPrice() { 

return price; 


J tteve’s our ytiev- mciKods - jus 七 

^ like ouv- previous 七 io 灼 • 


public boolean isVegetarian() 
return vegetarian; 

} 


public void print() { 

System, out .print ('' '、+ getName ()); 

if (isVegetarian ()) { 

System, out .print ('' (v)"); 

} 

System.out .println '、+ getPrice ()); 

System, out .println ('' -- '、 + getDescription ()); 

} 


This is -fv-om 七 he yevious 

Hcvc y/cVc ovcvvidmj 七 he method \r\ "the 

yV|cy»uCom^o^-t dlass. Fov Menultem tKis method 
七 he menu Ctvbry: dcsdvi^'tion, 

Y>r\U and or not its veggie- 
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composite structure 


Implementing the Composite Menu 

Now that we have the Menultem, we just need the composite class, which we’re 
calling Menu. Remember, the composite class can hold Menultems or other Menus. 
There’s a couple of methods from MenuComponent this class doesn’t implement: 
getPriceQ and isVegetarianQ, because those don’t make a lot of sense for a Menu. 


Me 的 u is also a /V|c^uCorir»j>oy>c^-t, 
just like /V|chu|-tcr»». v 


public class Menu extends MenuComponent { 

ArrayList menuComponents = new ArrayList() 
String name; 

String description; 


J 


public Menu(String name, String description) 
this.name = name; 
this.description = description; 

} 


Mervu 6a« have a«v 一 w < tUd 咖 

j twe MervuComyorveirvt, ^ell ^ a« 
m tev«al AvvavL-ist to hold these. 


This is di-P-Pc'rCh't ou\r old i 叶七 i。”: 
weW joihj -to jive cadK /l/|chu a name and a 
description. Bc*forc, v/C just relied oh KavihJ 
di-f-fcv-ch-t classes (ov mchu. 


public void add(MenuComponent menuComponent) { 

menuComponents.add(menuComponent); 

} 

public void remove(MenuComponent menuComponent) 
menuComponents.remove(menuComponent); 

} 


Wtrts \\o^ 70U add Mcr»u|-tcms or 
o-tKcv Mcr\us io a Because 

bo-tV) Mcnul-kcms M ⑽ s arc 
A/|c^uCom^onCr»-ts, v/C just oyxC 
method "to do botVv 

You darv also remove a Me ⑽ Com?o”C>vt 
or get a Mcr\uCom\>or\Cr\-t- 


public MenuComponent getChild(int i) { I 7 ow 

return (MenuComponent) menuComponents . get (i) ; ov- yt 3 Mc^uCor«^or\cr\ 

} 

^ - - ^ jettev methods -foy jci-tihj the ahd 

public String getName () { 匕 - desdrif-tioh. 


public String getName() 
return name; 

} 


public String getDescription() 
return description; 

} 



Mobtcj wc ovcv-rid'mj jctPvidcO ov isl/cyiavi 如 0 

because "those methods do /七 make schsc fov a /\/lcr\u 
(although you dould argue that isl/cjc-tanahO mijKi make 
set^). |*f somcohc tirics -to tall those mctKods Oh a AlchU, 

they’ll 釙 UhsuppovtcdOfcv-a-tiohE^dcptioh. 


public void print () { 

System, out .print ( 、、 \n" + getName ()); 

System. out.println ('', '、+ getDescription ()); 
System, out .println (、' - ,r ); 

} 


To Menu, v/c 卜七如 

\ - ^ A/|cr»us name drtd dcs 仏 iftion. 
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Wait a sec, I don't understand the 
implementation of print(). I thought I was 
supposed to be able to apply the same operations to a 
composite that I could to a leaf. If I apply print() to a 
composite with this implementation, all I get is a 
simple menu name and description. I don’t get a 
printout of the COMPOSITE. 


Excellent catch. Because menu is a composite and contains 
both Menu Items and other Menus, its printO method should 
print everything it contains. If it didn’t we’d have to iterate 
through the entire composite and print each item ourselves. 
That kind of defeats the purpose of having a composite 
structure. 

As you’re going to see, implementing printQ correctly is easy 
because we can rely on each component to be able to print 
itself. It’s all wonderfully recursive and groovy. Check it out: 


Fixing the priwtO method 


public class Menu extends MenuComponent { 

ArrayList menuComponents = new ArrayList(); 
String name; 

String description; 


// constructor code here 
// other methods here 


public void print() { 

System, out .print ( 、、 \n" + getName ()); 

System, out .println (、、， 、、 + getDescription ()); 
System, out .println (、、 - "）； 





Iterator iterator = menuComponents.iterator(). 
while (iterator.hasNext()) { 

MenuComponent menuComponent = 

(MenuComponent)iterator.next(); 
menuComponent.print(); 

} 




Look! 3^-t io use av\ l-tcvaiov. I/Vc 
use i*t to i*tcva-tc "tWoujK dll "tKc 
乙 … tKosc tould be Mct^us, 

or -t^cy ^ould be S'mdc bo*tK 

Mcr»us and /V|c»>u|-tcms ir^lemeivt y/C 

jusi ddll and -tKc vesi is to 


NOTE ： l-f, duv'mj -tKis i-tcvatioh, >wc e 灼亡 outvtev a^o-tKcv 

object, i"ts pvitvtO mctKod v/ill s-tavt a^oiKcv- i-tcvatioh, ar\d so or\. 
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test drive the menu composite 


fretting ready for a test drive... 


It’s about time we took this code for a test drive, but we need to update the Waitress code before 
we do — after all she’s the main client of this code: 


public class Waitress { 

MenuComponent allMenus; 


广 


public Waitress(MenuComponent allMenus) { 
this.allMenus = allMenus; 

} 

public void printMenu() { 
allMenus.print(); 

} 


V„ P I TV»e Wait 他 tode e . 

the that ^tam S aUV«e 
otV»L ">e«us. IA/eve tailed tV»at al 陳 ㈣. 

All sKe Kas io do io prm 七 ⑶七 ive menu 

Kicvav^Ky - all -tKc mcy\us, and all tKc 

items 一 is 匕 all ^v'm-to on { jo \ level menu. 
叫代 3o«« a have 0 «e happy Wa ■ 心 《 s . 


Okay, one last thing before we write our test drive. Let’s get an idea of what the menu 
composite is going to look like at runtime: 


Every Menu av\d 
yV|cr\u|-tcm -tKc 

/VlcnuCom^onCh-t mter-fade- 


Composite 、 


The ,evel holds all 

*»«►><« 扣 d 




Corwposi+e 




(X s ) 


EatK Menu 

%LJj UdsiW . 

。杜 e v_. 乂 

Q Q Q Q Q Q Q 


n 

Q Q Q 


0 7 

Leaf 


Leaf 


Q Q Q Q 


O 7 

/-ca-f 
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Now for the test drive... 

Okay, now we just need a test drive. Unlike our previous version, we’re going to 
handle all the menu creation in the test drive. We could ask each chef to give us 
his new menu, but let’s get it all tested first. Here’s the code: 


public class MenuTestDrive { 

public static void main(String args[] ) { 

MenuComponent pancakeHouseMenu = 

new Menu (''PANCAKE HOUSE MENU", ''Breakfast"); 

MenuComponent dinerMenu = 

new Menu (''DINER MENU", ''Lunch"); 

MenuComponent cafeMenu = 

new Menu (''CAFE MENU", ''Dinner"); 

MenuComponent dessertMenu = 

new Menu (''DESSERT MENU", ''Dessert of course !’’）； 

MenuComponent allMenus = new Menu (''ALL MENUS", ''All 




Let’s -f ivst trtait all 


Wc also rxttd W 七 o?, 
level mCrvu y\o^i II 


rvdme allMenus. 

combined"); 


allMenus.add(pancakeHouseMenu); 
allMenus.add(dinerMenu); 
allMenus.add(cafeMenu); 

// add menu items here 

dinerMenu.add(new Menultem( 
''Pasta", 



1/VcVc usmg -tKc Com^osiic addO mctKod -to add 

cadK rwChU -to -tKc "top level allMenus. 



|^o>/ v/c "to sdd 3 ll 

items, Vive’s o”C 
*fov v-cst, look 
a 七 souv-tc todt. 


''Spaghetti with Marinara Sauce, and a slice of sourdough bread". 


true, 

3.89)) ； ^ 一 ^ - v/cVc also adding a to a 

_All taves abou-t «s 七 

dinerMenu.add (dessertMenu) ; ^ ' cvev-yt^mg \i ^olds, it's d r«cr\u 

i 七 cm or a menu, is d 

dessertMenu.add(new Menultem( 

''Apple Pie", 

''Apple pie with a f la key crust, topped with vanilla icecream", 


true, 

1.59)); 

// add more menu items here 



Add some \>ic to tKc 
dessevt 


Waitress waitress = new Waitress(allMenus); 




waitress.printMenu(); 



仏 dc tov\sbr\Aticd ouv en-tive 

州 ⑶ u Wi^a^y, wc Kahd -the whole 

■tKihj *to *tKc lVai*tv*css, and as 
y ou，v c seen, its easy as apple pie 
•rov- hcv -to pvm-t i-t out 
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composite responsibilities 


fretting ready for a test drive... 

MOTB- -tKis ou-tfu-t is based ov\ -tKc domplc-tc source. 


I File Edit Window Help GreenEggs&Spam 


% java MenuTestDrive 

ALL MENUS, All menus combined 

ttcvc^s all our me 灼 us … v/e ^v-mtedi all tKis 

PANCAKE HOUSE MENU, Breakfast jus-t by dallmg on i\\t {x>^ level 


K&B , s Pancake Breakfast(v), 2.99 

--Pancakes with scrambled eggs, and toast 
Regular Pancake Breakfast, 2.99 

--Pancakes with fried eggs, sausage 
Blueberry Pancakes(v), 3.49 

--Pancakes made with fresh blueberries, and blueberry syrup 
Waffles (v) , 3.59 

--Waffles, with your choice of blueberries or strawberries 
DINER MENU, Lunch 


Vegetarian BLT(v), 2.99 

--(Fakin') Bacon with lettuce & tomato on whole wheat 
BLT, 2.99 

--Bacon with lettuce & tomato on whole wheat 
Soup of the day, 3.29 

--A bowl of the soup of the day, with a side of potato salad 
Hotdog, 3.05 

--A hot dog, with saurkraut, relish, onions, topped with cheese 
Steamed Veggies and Brown Rice(v), 3.99 
--Steamed vegetables over brown rice 
Pasta(v ), 3.89 

--Spaghetti with Marinara Sauce, and a slice of sourdough bread 


DESSERT MENU, Dessert of course! 



Apple Pie(v), 1.59 

--Apple pie with a flakey crust, topped with vanilla icecream 
Cheesecake(v), 1.99 

--Creamy New York cheesecake , with a chocolate graham crust 
Sorbet(v), 1.89 

--A scoop of raspberry and a scoop of lime 
CAFE MENU, Dinner 


TKc dessev-t 
is 

y/C 3v*c 


b\\ 



Veggie Burger and Air Fries(v), 3.99 

--Veggie burger on a whole wheat bun, lettuce, tomato, and fries 
Soup of the day, 3.69 

--A cup of the soup of the day, with a side salad 
Burrito(v), 4.29 " 

--A large burrito, with whole pinto beans, salsa, guacamole 
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Whafs the story? First you tell us 
One Class, One Responsibility, and now you 
are giving us a pattern with two responsibilities 
in one class. The Composite Pattern manages 
a hierarchy AND it performs operations 
related to Menus. 


There is some truth to that observation. We could say that the 
Composite Pattern takes the Single Responsibility design principle and 
trades it for transparency. What’s transparency? Well, by allowing the 
Component interface to contain the child management operations and 
the leaf operations, a client can treat both composites and leaf nodes 


uniformly; so whether an element is a composite or leaf node becomes 


transparent to the client. 


Now given we have both types of operations in the Component 
class, we lose a bit of safety because a client might try to do something 
inappropriate or meaningless on an element (like try to add a menu 
to a menu item). This is a design decision; we could take the design in 
the other direction and separate out the responsibilities into interfaces. 
This would make our design safe, in the sense that any inappropriate 
calls on elements would be caught at compile time or runtime, but we’d 
lose transparency and our code would have to use conditionals and the 
instanceof operator. 

So, to return to your question, this is a classic case of tradeoff. We are 
guided by design principles, but we always need to observe the effect 
they have on our designs. Sometimes we purposely do things in a way 
that seems to violate the principle. In some cases, however, this is a 
matter of perspective; for instance, it might seem incorrect to have 
child management operations in the leaf nodes (like add(), remove0 and 
getChildO), but then again you can always shift your perspective and see 
a leaf as a node with zero children. 
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flashback to iterator 


Flashback to Iterator 


We promised you a few pages back that we’d show you how to use Iterator 
with a Composite. You know that we are already using Iterator in our internal 
implementation of the printf) method, but we can also allow the Waitress to 
iterate over an entire composite if she needs to, for instance, if she wants to go 
through the entire menu and pull out vegetarian items. 

To implement a Composite iterator, let’s add a createlteratorO method in every 
component. We’ll start with the abstract MenuComponent class: 



vc added a ^v-catcl-tcv-a-tov-O mciKod 

■to -tKc TKis rwcans 

-tKat eadK /\/|cr»u a^d A^|cnu|-tcm Will 

{jo "tKis mg-tKod- |*t also 

means -tKa-t 6vca*tc|-tcv-a-tov0 on 

a dom^osi-tc sKould apply to all dKildv-c^ 
of -tKc dorw^osi-tc- 


Now we need to implement this method in the Menu and Menultem classes: 


public class Menu extends MenuComponent { 
Iterator iterator = null; - 


// other code here doesn^ t change 


only i\ttd ohc 
itc^ra-tov pcv- /VIcnu. 


fWc wcVc usihg a hew i-tcv-a-tov dal led 

Composi-tcl-tc^-tov. H khows how *to 
•icraic over a^y domposi-tc. 


public Iterator createlterator(> { 

if (iterator == null) { 

iterator = new Compositelterator(menuComponents•iterator())/ 

} 

return iterator; 

} 


广 ^ Wt fass i-t -tKc duvvchi 

V- dom^osi-tc^ i-teva-tov. 


public class Menultem extends MenuComponent { 

// other code here doesn't change 

public Iterator createlterator() { 

return new Nulllterator(); 

} 



Hovj -for -the Alchul-tcm... 

that's -this /Vul|/-tcv-a-tov? 
Vou II sec ih *tv/o pages. 
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The Composite Iterator 

The Compositelterator is a SERIOUS iterator. It’s got the job of iterating 
over the Menultems in the component, and of making sure all the child 
Menus (and child child Menus, and so on) are included. 


Here’s the code. Watch out, this isn’t a lot of code, but it can be a little mind 
bending. Just repeat to yourself as you go through it “recursion is my friend, 
recursion is my friend.” 


import j ava.util.*; 


C Likc all i 七 evatovs, wcVc 

java util.|-tcv-a-tov- 

m-tcv-fatc. 



Watch Ou r ： 

RliCUKSION 


public class Compositelterator implements Iterator { 
Stack stack = new Stack(); 


public Compositelterator(Iterator iterator) 
stack.push(iterator); 

} 


Tk i-tcira-tor o( -the -tof level 
domposi-tc wcVc go'mg -to rtevate ovev* 
is passed ir>. -tKv-ow *tKa*t m a 
s^tadk data s-tv-ud^tuve- 


Okay, when -tKc dieirt wah-b 

public Object next () { "to yt the dcmch-t v/c 

if (hasNext () ) { 仑《七 r«akc suve -tKcv-c is one 

Iterator iterator = (Iterator) stack.peek () ; by dallmg has/Voc-tO... 

MenuComponent component = (MenuComponent) iterator.next(); 
if (component instanceof Menu) { 

stack.push(component.createlterator()); 


return 
else { 
return 


component; 


null; 




\ 


public boolean hasNext() { 
if (stack.empty()) { 
return false; 

} else { 

Iterator iterator = (Iterator) 
if (!iterator.hasNext()) { 

stack.pop(); 
return hasNext(); 

} else { 

return true; 

} 


Otlicvy/isc theve is a 的 clcmcivt 

and vc 七 wrn tv-uc. 


"tKcV"C is ^ wc 

3ct the duirtCh 七 i-tev-a-tov- of-f *tKc 
s-tadk ahd jc-t its ncx-t element 

l-f -tKat elemetvt is a menu, Kavc 
anotKcv- do^fosi-tc needs to 
be mdluded m iKc iic\ration, so y/c 
七 Wo>w it on tKc s-btk. \v\ cit^cv- 
dasc, y/c v-ctuv-n 

To see i*f iiicv-c is a element 
y/e dKcdk to see i-f siatk is 
crwfty ； i*f so, tKcv-c isn’t 
OtKcv-y/isc, y/c get 七 ^ itev-a-tov 

o-f-f i\\t ioY o( s-btk and see 

i-f it Kas a element l-f i"t 
docs^t >wc y °? '"t o^*f s*tatk 
and ta\\ hasHe^iO vcduvsivcly. 




stack.peek(); 






public void remove() { 

throw new UnsupportedOperationException(); 

} 


WcVc 。七 su^ovtmj 
v-cw»ovc, just tv-avcvsal- 
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internal and external 


o 

Q 





That is serious code... I'm trying 
to understand why iterating over 
a composite like this is more difficult 
than the iteration code we wrote for 
printQ in the MenuComponent class? 


When we wrote the printQ method in the 
MenuComponent class we used an iterator to 
step through each item in the component and if 
that item was a Menu (rather than a Menultem), 
then we recursively called the printO method to 
handle it. In other words, the MenuComponent 
handled the iteration itself, internally. 

With this code we are implementing an external 
iterator so there is a lot more to keep track of. 

For starters, an external iterator must maintain its 
position in the iteration so that an outside client 
can drive the iteration by calling hasNextQ and 


nextQ. But in this case, our code also needs to 
maintain that position over a composite, recursive 
structure. That’s why we use stacks to maintain 
our position as we move up and down the 
composite hierarchy. 
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Draw a diagram of the Menus and Menultems. Then pretend you are the Compositelterator, and your job is 
to handle calls to hasNext() and next(). Trace the way the Compositelterator traverses the structure as this 
code is executed: 

public void testCompositeIterator(MenuComponent component) { 

Compositelterator iterator = new Compositelterator(component.iterator); 

while(iterator.hasNext()) { 

MenuComponent component = iterator.next(); 

} 

} 
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the null iterator 


The Noll Iterator 


Okay, now what is this Null Iterator all about? Think about it this way: a 
Menultem has nothing to iterate over, right? So how do we handle the 
implementation of its create Iterator 。 method? Well, we have two choices: 

Choice one: 

Return null 

We could return null from createlteratorQ, but then we’d 
need conditional code in the client to see if null was 
returned or not. 


㈣ & 


\c 




Choice two: 

Return an iterator that always returns 
false when hasNext() is called 

This seems like a better plan. We can still return an iterator, but 
the client doesn’t have to worry about whether or not null is ever 
returned. In effect, we’re creating an iterator that is a “no op”. 


The second choice certainly seems better. Let’s call it Nulllterator and 
implement it. 

import java.util.Iterator; 

public class Nulllterator implements Iterator { 


This is -the larics-t Itcvatov- youve 
ever seen, ai cvcv-y s-tep of -the 
way i-t puivts. 


public Object next () 
return null; 

} 



W\\ty\ ncx-tO is called ； v/e vetuvn null. 


public boolean hasNext() 
return false; 

} 


、 /Vlos-t impov-tan-tly y/Kcn is 

dalled >/e alv/ays v-c-tuvn -false. 


public void remove() { 

throw new UnsupportedOperationException(); 

} 


i\\t NJII-tcv-aiov- v/ould^t 
vemove- 
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frive me the vegetarian menu 

Now we’ve got a way to iterate over every item of the Menu. Let’s 
take that and give our Waitress a method that can tell us exactly 
which items are vegetarian. 


public class Waitress { 

MenuComponent allMenus; 


public Waitress(MenuComponent allMenus) { 
this.allMenus = allMenus; 


public void printMenu() { 
allMenus.print(); 



TKc ^v-'m-tl/cjctav-ianA^c^uO method 
takes tKc allMenus dom^osi-tc and 
y-b its iWatov-. TKa-t v/ill be ouv 
Composi 七 c I 七 e\ra 七 ov • 


public void printVegetarianMenu() { 

Iterator iterator = allMenus.createlterator(); 

System.out.println (''\nVEGETARIAN MENU\n - "); 

while (iterator.hasNext()) { 

MenuComponent menuComponent = 

(MenuComponent)iterator.next(); 

try { ^ 
if (menuComponent.isVegetarian()) { 

menuComponent.print(); 

} 

} catch (UnsupportedOperationException e) {} 

} 

} 


l/Vc implcmctvtcd isl/cgctav-iahO oy\ *tKc 
Alcnus -to always -tKv-ow c^dcp-tioh. If 
that Kappcw wc da-tdK -tKc bu-t 

don-tmuc wi*tK ouv i-tcvatioh. 


licv-atc 七 livou# 
cvcvy of 

torw^ositc- 

Call tat\\ 

a^d true, >/c tall ^ 


pirnrtO is 
Ohly dal led Oh 

Mchul-tcms, K»CVCV- 
domposi-tes. Cdh you 
see why? 
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magic of iterator and composite 

The magic of Iterator ^ Composite together:.. 

Whooo! It’s been quite a development effort to get our code to this point. Now we’ve got a general 
menu structure that should last the growing Diner empire for some time. Now it’s time to sit back and 
order up some veggie food: 



% java MenuTestDrive 
VEGETARIAN MENU 


K&B's Pancake Breakfast(v), 2.99 

--Pancakes with scrambled eggs, and toast 
Blueberry Pancakes(v), 3.49 

--Pancakes made with fresh blueberries, and blueberry syrup 
Waffles (v) , 3.59 

--Waffles, with your choice of blueberries or strawberries 
Vegetarian BLT(v), 2.99 

--(Fakin') Bacon with lettuce & tomato on whole wheat 
Steamed Veggies and Brown Rice(v), 3.99 

--Steamed vegetables over brown rice 
Pasta(v), 3.89 

--Spaghetti with Marinara Sauce, and a slice of sourdough bread 
Apple Pie(v), 1.59 

--Apple pie with a flakey crust, topped with vanilla icecream 
Cheesecake(v), 1.99 

--Creamy New York cheesecake , with a chocolate graham crust 
Sorbet(v), 1.89 

--A scoop of raspberry and a scoop of lime 
Apple Pie(v), 1.59 

--Apple pie with a flakey crust, topped with vanilla icecream 
Cheesecake(v), 1.99 

--Creamy New York cheesecake , with a chocolate graham crust 
Sorbet(v), 1.89 

--A scoop of raspberry and a scoop of lime 
Veggie Burger and Air Fries(v), 3.99 

--Veggie burger on a whole wheat bun, lettuce, tomato, and fries 
Burrito(v), 4.29 

--A large burrito, with whole pinto beans, salsa, guacamole 


TKc \/cgc"tav-ian doy\sis-ts o-f 

vcytavian items -from cvcvy 
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一 / I noticed in your 

printVegetarianMenu() method that you 
used the try/catch to handle the logic of the 
Menus not supporting the isVegetarian() method. 
—~I I’ve always heard that isn't good programming 
Nw form. / 


Let’s take a look at what you’re talking about: 


if (menuComponent.isVegetarian()) { 
menuComponent.print(); 

} 

} catch (UnsupportedOperationException) {} 


ss 二二 




ovt 


1 ( "tKc mChU dompohCh-t doesn’t support the 
opevatioh, v/c just tKvow away -the 
ijhovc it- 


In general we agree; try/catch is meant for error handling, 
not program logic. What are our other options? We could 
have checked the runtime type of the menu component with 
instanceof to make sure it’s a Menultem before making the 
call to isVegetarian0. But in the process we’d lose transparency 
because we wouldn’t be treating Menus and Menultems 
uniformly. 

We could also change isVegetarianO in the Menus so that it 
returns false. This provides a simple solution and we keep our 
transparency. 

In our solution we are going for clarity: we really want to 
communicate that this is an unsupported operation on the 
Menu (which is different than saying isVegetarianO is false). It 
also allows for someone to come along and actually implement 
a reasonable isVegetarianO method for Menu and have it work 
with the existing code. 

That’s our story and we’re stickin’ to it. 


interview with composite 



Pattern Exposed 

This week’s interview: 

The Composite Pattern, on Implementation 


issues 


Head First: We’re here tonight speaking with the 
Composite Pattern. Why don’t you tell us a little about 
yourself, Composite? 

Composite ： Sure... I’m the pattern to use when you 
have collections of objects with whole-part relationships 
and you want to be able to treat those objects uniformly. 

HeadFirst: Okay, let’s dive right in here... what do you 
mean by whole-part relationships? 

Composite: Imagine a graphical user interface; there 
you’ll often find a top level component like a Frame or 
a Panel, containing other components, like menus, text 
panes, scrollbars and buttons. So your GUI consists 
of several parts, but when you display it, you generally 
think of it as a whole. You tell the top level component 
to display, and count on that component to display all 
its parts. We call the components that contain other 
components, composite objects, and components that 
don’t contain other components, leaf objects. 

Head First: Is that what you mean by treating the 
objects uniformly? Having common methods you can 
call on composites and leaves? 

Composite ： Right. I can tell a composite object to 
display or a leaf object to display and they will do the 
right thing. The composite object will display by telling 
all its components to display. 

Head First: That implies that every object has the same 
interface. What if you have objects in your composite 
that do different things? 

Composite: Well, in order for the composite to work 
transparently to the client, you must implement the same 
interface for all objects in the composite, otherwise, the 
client has to worry about which interface each object 
is implementing, which kind of defeats the purpose. 
Obviously that means that at times you’ll have objects for 
which some of the method calls don’t make sense. 

Head First: So how do you handle that? 


Composite ： Well there’s a couple of ways to handle 
it; sometimes you can just do nothing, or return null or 
false - whatever makes sense in your application. Other 
times you’ll want to be more proactive and throw an 
exception. Of course, then the client has to be willing to 
do a little work and make sure that the method call didn’t 
do something unexpected. 

Head First: But if the client doesn’t know which kind 
of object they’re dealing with, how would they ever know 
which calls to make without checking the type? 

Composite ： If you’re a little creative you can structure 
your methods so that the default implementations do 
something that does make sense. For instance, if the 
client is calling getChildO, on the composite this makes 
sense. And it makes sense on a leaf too, if you think of 
the leaf as an object with no children. 

HeadFirst: Ah... smart. But, I’ve heard some clients 
are so worried about this issue, that they require separate 
interfaces for different objects so they aren’t allowed 
to make nonsensical method calls. Is that still the 
Composite Pattern? 

Composite: Yes. It’s a much safer version of the 
Composite Pattern, but it requires the client to check the 
type of every object before making a call so the object 
can be cast correctly. 

Head First: Tell us a little more about how these 
composite and leaf objects are structured. 

Composite ： Usually it 5 s a tree structure, some kind of 
hierarchy. The root is the top level composite, and all its 
children are either composites or leaf nodes. 

Head First: Do children ever point back up to their 
parents? 

Composite! Yes, a component can have a pointer to a 
parent to make traversal of the structure easier. And, if 
you have a reference to a child, and you need to delete it, 
you’ll need to get the parent to remove the child. Having 
the parent reference makes that easier too. 
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Head First: There’s really quite a lot to consider in your 
implementation. Are there other issues we should think 
about when implementing the Composite Pattern? 

Composite ： Actually there are... one is the ordering 
of children. What if you have a composite that needs to 
keep its children in a particular order? Then you’ll need 
a more sophisticated management scheme for adding and 
removing children, and you’ll have to be careful about 
how you traverse the hierarchy. 

Head First: A good point I hadn’t thought of. 

Composite ： And did you think about caching? 

HeadFirst: Caching? 

Composite ： Yeah, caching. Sometimes, if the 
composite structure is complex or expensive to traverse, 
it’s helpful to implement caching of the composite nodes. 
For instance, if you are constantly traversing a composite 
and all its children to compute some result, you could 
implement a cache that stores the result temporarily to 
save traversals. 

HeadFirst ： Well, there’s a lot more to the Composite 
Patterns than I ever would have guessed. Before we 
wrap this up, one more question: What do you consider 
your greatest strength? 

Composite ： I think I’d definitely have to say 
simplifying life for my clients. My clients don’t have to 
worry about whether they’re dealing with a composite 
object or a leaf object, so they don’t have to write if 
statements everywhere to make sure they’re calling the 
right methods on the right objects. Often, they can make 
one method call and execute an operation over an entire 
structure. 

HeadFirst ： That does sound like an important benefit. 
There’s no doubt you’re a useful pattern to have around 
for collecting and managing objects. And, with that, 
we’re out of time... Thanks so much for joining us and 
come back soon for another Patterns Exposed. 



crossword puzzle 



Across 

1. User interface packages often use this pattern 
for their components. 

3. Collection and Iterator are in this package 

5. We encapsulated this. 

6. A separate object that can traverse a 
collection. 

10. Merged with the Diner. 

12. Has no children. 

13. Name of principle that states only one 
responsibility per class. 

14. Third company acquired. 

15. A class should have only one reason to do 
this. 

16. This class indirectly supports Iterator. 

17. This menu caused us to change our entire 
imDlementation. 


Down 

1. A composite holds this. 

2. We java-enabled her. 

4. We deleted PancakeHouseMenulterator 
because this class already provides an iterator. 

5. The Iterator Pattern decouples the client from 

the aggregates_. 

7. Compositelterator used a lot of this. 

8. Iterators are usually created using this 
pattern. 

9. A component can be a composite or this. 

11. Hashtable and ArrayList both implement this 
interface. 
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the iterator and composite patterns 



Match each pattern with its description: 


Pattern 

Description 

Strategy 

Clients txesd collections P? 
objects cind Individual objects 

uniformly 

Adapter 

iter^ttpr 

Provides a wa/tp traVerse a 
collection o? objects Without 
exposing the collection’s 

Implement 批 km 

Simplifies the Interface of a 
group of clcisses 

Facade 

the Interface o? one 
or more classes 

ConipPsite 

Allows a group of objects tP 

be notified wjien SPtne stclte 

ct^inges 

Observer 

Encapsulcites Irrtercjicingeable 
beJiaViPrs cind uses delegcttiQn 
io decide which QmtQ uses 


you are here 





your design toolbox 


Tc 

J / Two ne 
to deal 


Tools for your Pesigw Toolbox 


new patterns for your toolbox - two great ways 
，al with collections of objects. 
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BULLET POINTS 


An Iterator allows access to an 
aggregate’s elements without 
exposing its internal structure. 

An Iterator takes the job of 
iterating over an aggregate 
and encapsulates it in another 
object. 

When using an Iterator, we 
relieve the aggregate of the 
responsibility of supporting 
operations for traversing its 
data. 

An Iterator provides a common 
interface for traversing the 
items of an aggregate, allowing 
you to use polymorphism when 
writing code that makes use of 
the items of the aggregate. 

We should strive to assign 
only one responsibility to each 
class. 

The Composite Pattern 
provides a structure to hold 
both individual objects and 
composites. 

The Composite Pattern allows 
clients to treat composites and 
individual objects uniformly. 

A Component is any object 
in a Composite structure. 
Components may be other 
composites or leaf nodes. 

There are many design 
tradeoffs in implementing 
Composite. You need to 
balance transparency and 
safety with your needs. 
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Exercise solutions 


Sharpen your pencil 


Based on our implementation of printMenuQ, which of the following apply? 


We are coding to the 
PancakeHouseMenu and DinerMenu 
concrete implementations, not to an 
interface. 

口 B. The Waitress doesn’t implement the 

Java Waitress API and so isn’t adhering 
to a standard. 

C. If we decided to switch from using 
DinerMenu to another type of menu 
that implemented its list of menu items 
with a Hashtable ， we’d have to modify 
a lot of code in the Waitress. 


U^D. The Waitress needs to know how each 

menu represents its internal collection of 
menu items is implemented, this violates 
encapsulation. 

lar^E. We have duplicate code: the printMenu() 
method needs two separate loop 
implementations to iterate over the two 
different kinds of menus. And if we 
added a third menu, we might have to 
add yet another loop. 

[I F. The implementation isn’t based on 
MXML (Menu XML) and so isn’t as 
interoperable as it should be. 



rpen your pencil 


Before turning the page, quickly jot down the three things we have 
to do to this code to fit it into our framework: 


I. implement iKe Menu \v\icr(au 


2.. jet v-id of gctl-tcmsO 


j,. add drca-tclicva-tovO v-c-tuv-h a»^ licva-tov -tKat t^y\ step -tKvoujK -tKc ttasK-tablc values 
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Code Magnets Solution 

The unscrambled "Alternating” DinerMenu Iterator 


import java.util.Iterator; 
import java.util.Calendar; 


public_class AlternatingDinerMenuIterator _ / ^piementf 




Menultem[] items; 
int position; 


I public AlternatingDinerMenuIterator (Menultem [^temsjj 


this.items = items; 

Calendar rightNow = Calendar.getlnstance(); 
f^f_ ltlon = rightNow.get (Calendar.DAY OF WEEK) % 2; 


□ 


public boolean hasNext() { 



if (position >= items.length || items[position] =- null) { 

return false; 

} else { 

return true; 


G] 


[^^Obj ect nextQ 7| 

□ 

Menultem menultem = 
position = position 
return menultem; 

items[position]; 

+ 2; 



public void remove() { | 



Kotldc -tWis litraior 

implerwetvta 七 IO 灼 docs Y\o{, 

suppovt VCrwoVcO 


tnrow new UnsupportedOperationException( 

Alternating Diner Menu Iterator does not support remove()")• 

□ □ - - - ： 
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Match each pattern with its description: 

Pattern 



the iterator and composite patterns 




Description 


Clients treat collections o? 
objects £Uld Individual objects 
unifcrmly 

provides a wa/tp traVerse a 
cpllectipn o? objects WitJiPUt 
exposing tte cpllectiPii's 
lmplementatipn 

Simplifies the Interface o? a 
group p? classes 


Ch^Jlg^s tte Interface o? one 
、■ more closes 

Allows a group p? objects tP 
be nPdfied wten some state 
、 changes 

\ Encapsulates lntercjifm^eaUe 
beliaViPrs £Uld uses delegsttiQn 
iQ decide wtlcji one to uses 


you are here 





crossword puzzle solution 



Exercise solutions 
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10 the St^e fstttem 


♦ The State of Things 


w 



A little known fact: the Strategy and State Patterns were twins 

Separated at birth. As you know, the Strategy Pattern went on to create a wildly 
successful business around interchangeable algorithms. State, however, took the perhaps 
more noble path of helping objects to control their behavior by changing their internal 
state. He’s often overheard telling his object clients, “Just repeat after me: I’m good 
enough, I’m smart enough, and doggonit …” 


this is a new chapter 
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meet mighty gumball 


V 玖 

Jaw breakers 


Java toasters are so c 90s. Today people are buildingjava into 
real devices, like gumball machines. That 5 s right, gumball 
machines have gone high tech; the major manufacturers have 
found that by putting CPUs into their machines, they can 
increase sales, monitor inventory over the network and measure 
customer satisfaction more accurately. 

But these manufacturers are gumball machine experts, not 
software developers, and they’ve asked for your help: 


: 7 ) . a ^ yvccdcd 




V\^here the Gumball Machine 
h Ik Ne^ef H5lf trnpty f _ 


w 知—叫 vo« to k« ? 
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the state pattern 



Let's take a look 
at this diagram and see 
what the Mighty Gumball 
guys want... 


Cubicle Conversation 


Anne ： This diagram looks like a state diagram. 

Joe ： Right, each of those circles is a state... 

Anne ： ... and each of the arrows is a state transition. 

Frank: Slow down, you two, it’s been too long since I studied state diagrams. 
Can you remind me what they’re all about? 

Anne ： Sure, Frank. Look at the circles; those are states. “No Quarter 55 is 
probably the starting state for the gumball machine because it’s just sitting 
there waiting for you to put your quarter in. All states are just different 
configurations of the machine that behave in a certain way and need some 
action to take them to another state. 


Joe ： Right. See, to go to another state, you need to do something like put a quarter in the machine. See the arrow 
from “No Quarter 55 to “Has Quarter? 55 

Frank ： Yes... 


Joe ： That just means that if the gumball machine is in the “No Quarter 55 state and you put a quarter in, it will 
change to the “Has Quarter 55 state. That’s the state transition. 

Frank: Oh, I see! And if I’m in the “Has Quarter 55 state, I can turn the crank and change to the “Gumball Sold” 
state, or eject the quarter and change back to the “No Quarter 55 state. 

Anne ： You got it! 

Frank: This doesn’t look too bad then. We’ve obviously got four states, and I think we also have four actions: “inserts 
quarter，” “ejects quarter，” “turns crank” and “dispense.” But... when we dispense, we test for zero or more gumballs 
in the “Gumball Sold” state, and then either go to the “Out of Gumballs” state or the “No Quarter 55 state. So we 
actually have five transitions from one state to another. 

Anne ： That test for zero or more gumballs also implies we’ve got to keep track of the number of gumballs too. Any 
time the machine gives you a gumball, it might be the last one, and if it is, we need to transition to the “Out of 
Gumballs” state. 


Joe ： Also, don’t forget that you could do nonsensical things, like try to eject the quarter when the gumball machine 
is in the “No Quarter 55 state, or insert two quarters. 

Frank: Oh, I didn’t think of that; we’ll have to take care of those too. 

Joe ： For every possible action we’ll just have to check to see which state we’re in and act appropriately. We can do 
this! Let’s start mapping the state diagram to code... 


you are here 
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State machines 101 


How are we going to get from that state diagram to actual code? Here’s a quick 
introduction to implementing state machines: 


First, gather up your states: 



Next, create an instance variable to hold the current state, and define values for each of the states: 


Lets 

w Soia 


jus 七 tall o*f 石 

Q\a\!! •('OV s^ovt- 


final static 
final static 
final static 
final static 


int SOLD_OUT = 0; 
int NO_QUARTER = 1; 
int HAS_QUARTER = 2; 
int SOLD = 3; 


int state = SOLD OUT; 



Heves eatV> slate veyvese^ted 
ds d mtcyv- - 

...aY\d an variable tKa-t holds -tKc 

^uvv-c^-t s-tatc- V^/tW 30 aKead and set \i to 
u Sold Ou*t w sinde *tKe mddKme >/ill be un-fillcd 
it’s -f iv-s-t -taken ou-t o( i-ts box. and "tuwd cm. 


Now we gather up all the actions that can happen in the system: 



TV>csc att>o^s 3v*c 

msevts <\wav-tev- iuirns 

I 七 he ^umbdii m3d.Wnr\C s 
m-bev^ate - tWmy 

^ ■— 

ejects <\uav-tcv- 

you tBr\ do it 

dispc^sc 



Dispense is move o( a>^ m-tcv^al 

Look'ma at tv>e diayam, mvokm 3 a«v these 
attics tauses a slate 

a^tioh -tKc ma^K'mc invokes or\ i-tscl-f. 
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the state pattern 


Now we create a class that acts as the state machine. For each action, 
we create a method that uses conditional statements to determine 
what behavior is appropriate in each state. For instance, for the insert 
quarter action, we might write a method like this: 


possible 
s-tatc is 

a Conditional 
s*ta 七 emetvt … 


public void insertQuarter() { 

if (State == HAS_QUARTER) { 

System, out .println (''You can't insert another quarter"); 

} else if (state == SOLD—OUT) { 

System, out .println (''You can't insert a quarter, the machine i^/sold out 〃）； 
} else if (state == SOLD) { 

System, out .println (''Please wait, we're already giving you a gumball 〃）； 

} else if (state == NO QUARTER) { 



State = HAS_QUARTER; 

System, out .println (''You inserted a quarter"); 






W tacM 


...bu-t tav\ also -tvansition io o-tKcv 
s-ta-tes, just as diagv-a^. 


Here were talking 
about a common technique ： 
modeling state within an object 
by creating an instance variable to hold 
the state values and writing conditional 
code within our methods to handle 
the various states. 


"that <\uidk review, implemeivt 七 he ^umbdll 
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Writing the code 


It’s time to implement the Gumball Machine. We know we’re going to have an instance 
variable that holds the current state. From there, we just need to handle all the actions, 
behaviors and state transitions that can happen. For actions, we need to implement inserting 
a quarter, removing a quarter, turning the crank and dispensing a gumball; we also have the 
empty gumball condition to implement as well. 


public class GumballMachine { 

final static int SOLD—OUT = 0; 
final static int NO 一 QUARTER = 1; 
final static int HAS_QUARTER = 2; 
final static int SOLD = 3; 



Wert avc ^ ^°' 




int state 
int count 


SOLD OUT; 
0； 


public GumballMachine(int count) 
this.count = count; 
if (count > 0) { 

state = NO 一 QUARTER; 

} 


state a.a^. 

Here's -the ms-ta^e vaviable is aomj to 

kee? tvatk o-f tv«e state 批代 ，《. 

吣如 “ 如 S 0 LP_ 0 WT 抓 

hvc a sedohd ms-tahde variable -tha-t 
keeps -tvadk o( -the nurwbev* o( gumballs m 

"the 

Tk dons-tirud-toir "takes ah m'rtial 
■^ioyy 9 ur«balls. iHhe mvey,ioyy 
isn 七 zero, -the macKiine en-iers s-ta-te 
I^O_^UfiRTBR, roeaniing i-t is wai-tih^ (or 
someone io mseiri a ， 七饮 , oihevv/ise 

siays m ihe S0Lt>_0UT sisie- 


-tv,e as …' 


public void insertQuarter() { 

if (state == HAS_QUARTER) { 

System, out .print In (''You can’t insert another quarter’’） 

} else if (state == NO_QUARTER) { 

State = HAS_QUARTER; 

System, out .println (''You inserted a quarter”）； 

} else if (state == SOLD—OUT) { 

System, out .println (''You can't insert a quarter, the machine is sold out〃）； 
} else if (state == SOLD) { 

System, out .println (''Please wait, we r re already giving you a gumball"); 


d charier is msevtcd, >-f •• 

a <^uav-tcv- is already msevtcd 
-tell dustorwCV ； 

0-tV^cvWisc v/c atuyi Ac 
<^uav-tcv- at\d -tv-ar\siiior» io 

⑽ SJ$IXART£R s-b-kc- 


} 


|*f 七 he d-us-torwCV- jus 七 boug^-t 3 
gumball Ke needs -to v/ait utvtil 七 ^ 
bra^athoY^ is dom\>lc-tc before 
mscvtmj a^ct^cv - ^uav-tev - - 


w»3^mC is sold 
ou-t, y/C quarter. 
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< 0 Kow, i-f lv.e duslomev Ivies to «»ove tV.e <\ua 士 r... 

K tV>eve is a ^v-tev, 

i-t a«a 50 batk to 

the NO J$WAR 似址 . 

在 - O-tKcvv/isc, i-f -tKcv*c isy / 七 

System, out .print In (''You haven f t inserted a quarter ’’）； or»c y/c dan^ jive it badk. 


public void ejectQuarter() 

if (State == HAS 一 QUARTER) { 

System, out .println (''Quarter returned ’'）； 
state = NO_QUARTER; 

} else if (state == NO QUARTER) { 


else if (state == SOLD) { 

System, out .println (''Sorry, you already turned the crank :〃） ； 
else if (state == SOLD_OUT) { 

System, out .println (''You can't eject, you haven f t inserted a quarter yet 〃）； 


^/ou 匕 an’ 七 cjcdt i-f "tKc is sold 

oui, i 七 does / 七 <\uartcvs| 

TKc dus-tomcv br\ts io -tuv-r^ i\\t 

^Someone’s 七 vying 七。 Aea 七 madWmc- 



l-P tKc dus 七 omev jus 七 
-turned -tKc ^v*a^k, y/c 匕 an ’ 七 
jive a v-c-fund; Kc alv-cady 
Kas tKc jumballl 


public void turnCrank() { 

if (state == SOLD) { 

System, out .println (''Turning twice doesn't get you another gumball \ "); 


else if (state == NO_QUARTER) { 

System, out .println (''You turned but there's no quarter ”）； ^ 
else if (state == SOLD 一 OUT) { 

System, out .println (''You turned, but there are no gumballs ”）； 
else if (state == HAS_QUARTER) { 

System, out .println (''You turned. ••’’）； 
state = SOLD; — 


l/Vc a 

<\uavtcv- -fivst. 

\A/c dclWcr 
^umbdlU ； 細 c 
arc y\oy\C 


dispense (); 


^~^ Called "to disj>c^sc a gumball- 


Suddcssj They yt 3 jumbal I. 

七 he s*t«i-tc "to SOL-P tall 

marine’s dis^Ci^scO method• 

public void dispense () { yy/ c Vc 

if (state == SOLD) { C SOUP state 5 We 

System, out .println (''A gumball comes rolling out the slot ’’）； v a auwbaU! 

count = count - 1; 
if (count == 0) { 

System, out .println (''Oops, out of gumballs !") 
state 二 SOLD—OUT; 

} else { 

State 二 NO QUARTER; 


} 

else if (state == NO_QUARTER) { 

System, out .println (''You need to pay first 〃）； 
else if (state == SOLD_OUT) { 

System, out .println (''No gumball dispensed"); 
else if (state == HAS_QUARTER) { 

System, out .println (''No gumball dispensed"); 


丄 o :), 


匕以 — aUs,W “ 

-atWme s state 


ba 上 — 狄 

KohC o( these should 
cvev- Kaffch, bu-t i-f 

they do, wc give cm ah 

c'rv-ov, noi a gumball- 


〆 


// other methods here like toString () and refill () 
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test the gumball machine 


lw - house testing 


That feels like a nice solid design using a well-thought out methodology doesn’t 
it? Let’s do a little in-house testing before we hand it off to Mighty Gumball to 
be loaded into their actual gumball machines. Here’s our test harness: 


public class GumballMachineTestDrive { 

public static void main(String[] args) { 

GumballMachine gumballMachine = new GumballMachine(5) 




Load \i ^ 

-(•'iVC ^urmbdlls 七 


System.out.println(gumballMachine); 


gumballMachine.insertQuarter(); 
gumballMachine.turnCrank(); 


System.out.println(gumballMachine); 


gumballMachine.insertQuarter(); 
gumballMachine.ejectQuarter(); 
gumballMachine.turnCrank(); 


System.out.println(gumballMachine); 


gumballMachine.insertQuarter(); 
gumballMachine.turnCrank(); 
gumballMachine.insertQuarter(); 
gumballMachine.turnCrank(); 
gumballMachine.ejectQuarter(); 


System.out.println(gumballMachine); 


gumballMachine.insertQuarter(); 
gumballMachine.insertQuarter(); 
gumballMachine.turnCrank(); 
gumballMachine.insertQuarter(); 
gumballMachine.turnCrank(); 
gumballMachine.insertQuarter(); 
gumballMachine.turnCrank(); 



Pv-ih-t out -tKc s-tatc of -tKc ^ 

TKv-ov/ a ^uavtcv- m." 

Tuv-h -tKc dvar\k ； >wc should yt ouv jumbalI- 

Pv'm-t ou-t s-ta-tc aga'm. 

TKv-ow B ^uav-tcv m... 

/\sk -fov it bddk. 

Tuv-h -tKc dva^k ； v/C shouldn't jet ouv gumball-. 

Pv'rn-t ou-t siait of maAmc, again- 

TKvov/ b ^uavtcv- \v\... • 

Tuvr» "tKc dvdhk ； >wc should ouv gumball 
TKvov/ a ^uavtcv m... 

Tuvh "tKc dva^k ； >wc should jet ouv- gumball 
Ask -fov a <\uav-tcv- ba^k v/e didh’i pu-t m. 

Pv-'m-t ou-t s-ta-tc aga'm- 

TKvov/ TWO 气 uavtevs m". 

Tuv-h -tKc dva^k ； >wc should yt ouv gumball- 

No>w -fov- -tKc s-tv-css -tcs-t'mj... Q 




System.out.println(gumballMachine); 


pvitvt -tKa-t madKmc s-ta-tc Ohc move -time. 
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File Edit Window Help mightygumball.com 


% java GumbalIMachineTestDrive 
Mighty Gumball, Inc. 

Java-enabled Standing Gumball Model #2004 

Inventory : 5 gumballs 

Machine is waiting for quarter 

You inserted a quarter 
You turned... 

A gumball comes rolling out the slot 
Mighty Gumball, Inc. 

Java-enabled Standing Gumball Model #2004 

Inventory : 4 gumballs 

Machine is waiting for quarter 

You inserted a quarter 
Quarter returned 

You turned but there's no quarter 
Mighty Gumball, Inc. 

Java-enabled Standing Gumball Model #2004 

Inventory : 4 gumballs 

Machine is waiting for quarter 


You inserted a quarter 
You turned... 

A gumball comes rolling out the slot 
You inserted a quarter 
You turned... 

A gumball comes rolling out the slot 
You haven't inserted a quarter 


Mighty Gumball, Inc. 

Java-enabled Standing Gumball Model #2004 

Inventory : 2 gumballs 

Machine is waiting for quarter 


You inserted a quarter 

You car^t insert another quarter 

You turned... 

A gumball comes rolling out the slot 
You inserted a quarter 
You turned... 

A gumball comes rolling out the slot 
Oops, out of gumballs! 

You can't insert a quarter, the machine is sold out 
You turned, but there are no gumballs 


Mighty Gumball, Inc• 

Java-enabled Standing Gumball Model #2004 
Inventory : 0 gumballs 
Machine is sold out 
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gumball buying game 


You knew it was coming... a change request! 

Mighty Gumball, Inc. has loaded your code into their new¬ 
est machine and their quality assurance experts are putting 
it through its paces. So far, everything’s looking great from 
their perspective. 

In fact, things have gone so smoothly they’d like to take 
things to the next level... 


r 

ceo , 料 切 

or 



We think that by turning 
''gumball buying" into a game we 
can significantly increase our 
sales. Were going to put one of 
these stickers on every machine. 
We re so glad weve got Java 
in the rwachmes because this is 
going to be easy, right? 
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IXse A^Ii^K-ty ^umball s s-ta-tior>avy -to dv-aw your s-ta-te dia^v-am. 
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things get messy 


The messy STATE of things... 


Just because you’ve written your gumball machine using a well-thought out methodology doesn’t 
mean it’s going to be easy to extend. In fact, when you go back and look at your code and think 
about what you’ll have to do to modify it, well... 


final static 
final static 
final static 
final static 


int SOLD 一 OUT = 0; 
int NO_QUARTER = 1; 
int HAS_QUARTER = 2; 
int SOLD = 3; 


you a to add a 

T\\ai -to© bad." 




public void insertQuarter() { 

// insert quarter code here 

} 

public void ejectQuarter() { 

// eject quarter code here 


public void turnCrank() { 

// turn crank code here 

} 

public void dispense() { 

// dispense code here 

} 


' but youd have b> add a «ew t 一 i 七 

一 evev-7 melVtod io handle lV>e LINKER slate; 

-thaVs a lo-t of tode 


七 uv^Or 扣 kO v/ill cs^dially r^cssy, because 

youd Kavc -to add dodc io dKcdk to see 
youve Jo-t a DINNER and sy/rtdV> to cit^cv- 

七 k WINNER state or SOLP state- 



Which of the following describe the state of our implementation? 
(Choose all that apply.) 


Q A. This code certainly isn’t adhering to the 
Open Closed Principle. 

Q B. This code would make a FORTRAN 
programmer proud. 

d C. This design isn’t even very object 
oriented. 


Q C. State transitions aren’t explicit; they 

are buried in the middle of a bunch of 
conditional statements. 

口 D. We haven’t encapsulated anything that 
varies here. 

[I E. Further additions are likely to cause bugs 
in working code. 
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Okay, this isn’t good. I think 
our first version was great, but 
it isn't going to hold up over time as Mighty 
Gumball keeps asking for new behavior. The 
rate of bugs is just going to make us look 
bad, not to mention that CEO will drive 
us crazy. 


Joe ： You’re right about that! We need to refactor this code so that it’s easy 
to maintain and modify. 

Anne ： We really should try to localize the behavior for each state so that if 
we make changes to one state, we don’t run the risk of messing up the other 
code. 

Joe ： Right; in other words, follow that ol 5 “encapsulate what varies” 
principle. 

Anne ： Exactly. 

Joe ： If we put each state’s behavior in its own class, then every state just 
implements its own actions. 

Anne ： Right. And maybe the Gumball Machine can just delegate to the 
state object that represents the current state. 

Joe ： Ah, you’re good: favor composition... more principles at work. 


Anne ： Cute. Well, I’m not 100% sure how this is going to work, but I think 
we’re on to something. 

Joe ： I wonder if this will this make it easier to add new states? 

Anne ： I think so... We’ll still have to change code, but the changes will be 
much more limited in scope because adding a new state will mean we just 
have to add a new class and maybe change a few transitions here and there. 

Joe ： I like the sound of that. Let’s start hashing out this new design! 
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The new design 

It looks like we’ve got a new plan: instead of maintaining our existing code, we’re going to 
rework it to encapsulate state objects in their own classes and then delegate to the current 
state when an action occurs. 

We’re following our design principles here, so we should end up with a design that is easier to 
maintain down the road. Here’s how we’re going to do it: 

❶ First, we’re going to define a State interface that 
contains a method for every action in the Gumball 
Machine. 

❺ Then we’re going to implement a State class for 
every state of the machine. These classes will be 
responsible for the behavior of the machine when it 
is in the corresponding state. 

❺ Finally, we’re going to get rid of all of our conditional 
code and instead delegate to the state class to do 
the work for us. 


Not only are we following design principles, as you’ll see, we’re actually implementing the 
State Pattern. But we’ll get to all the official State Pattern stuff after we rework our code... 



398 Chapter 10 



Pefining the State interfaces avid classes 

First let's create an interface for State, which all our states implement: 


the state pattern 


lV>e miev-fate U all slates. The ^ 

io atlio«s Ua-t tould -to lV>e $_ball MatWe (U«e 

the same me^ods as m the previous todel 


avc 



Then take each state iw our design 
and encapsulate it in a class that 
impletuents the State interface. 


«interface» 

State 

insertQuarter() 

ejectQuarter() 

turnCrank() 

dispense() 

V 习 f 勺 


To ^ijuvc out 4a 七 

s*ba*bcs v/c y\ccd, ^ look ^ 

3 -t, ouv ^>vcv'»ous todt- J 





SoldState 


SoldOutState 


NoQuarterState 


HasQuarterState 

insertQuarter() 

ejectQuarter() 


insertQuarter() 

ejectQuarter() 


insertQuarter() 

ejectQuarter() 


insertQuarter() 

ejectQuarter() 


turnCrank() 


turnCrank() 


turnCrank() 


turnCrank() 

[ 

dispense() 


dispense() 


dispense^ 


dispense() 



... and v/e c3^ s-tatc 
div-ctilY to a tlass. 


Po^t -fovjel, we «eed a «ew V ⑽ ev” s-tale loo 
Ual i 叶一 e «ts 如 siaie 'mle^ate- lA/ell to»e 
batk io iV>is a-fiev we vei»\>le»ent the 
vcvsio^ o-f *tV\C ^umbsll A^3^iy»C- 



WinnerState 

insertQuarter() 

ejectQuarter() 

turnCrank() 

dispense)) 
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what are all the states? 


Sharpen your pencil 


To implement our states, we first need to specify the behavior of the classes 
when each action is called. Annotate the diagram below with the behavior of 
each action in each class; we’ve already filled in a few for you. 


6\o bo ttas^uav-tcv-S-tatc 
Tell "tKc dus-torwev-, 'You haven't ihscvtcd B 



NoQuarterState 

insertQuarter() 

ejectQuarter() 

turnCrank() 

dispense() 


今 o 七 。 SoldSiaic 




HasQuarterState 

insertQuarter() 

ejectQuarter() 

turnCrank() 

dispense() 


Tell 七 he <tus-tomcv, W PIcase wait, v/cVc alv-cady givmg you a gumball ” 



Dispense ohC jumbal I • Chcdk humbeir o( Jumbal Is ； i-f > O, go 
lo No 夕 o-thcrwisc, go b> SoldOu-tS-tatc 


SoldState 

insertQuarter() 

ejectQuarter() 

turnCrank() 

dispense 。 


Tell the dusiomcv, w TKcvc arc no gumbalk” 



SoldOutState 

insertQuarter() 

ejectQuarter() 

turnCrank() 

dispense() 


WinnerState 


insertQuarter() 

ejectQuarter() 

turnCrank() 

dispense() 


勹 


与 。 ahead a^d -fill "this ou-t CVCh -though v/cVc implcmchtmj it latcv*- 
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Implementing our State classes 

Time to implement a state: we know what behaviors we want; we just need to get it down in code. We’re going to 
closely follow the state machine code we wrote, but this time everything is broken out into different classes. 

Let’s start with the NoQjaarterState: 






public class NoQuarterState implements State { 
GumballMachine gumbalIMachine; 

public NoQuarterState(GumballMachine gumballMachine) 
this.gumballMachine = gumballMachine; 

} 


Wt yi passed a \rc-fcv-chdc b> 

七 he jumbal I Matli'mc - thv-oujli ilic 
tor\si\rut-to\r. iVcVc jusi io 
-this *m 3iy\ 'ms-tahtc vav-iablc. 

|-f someone msev^bs 3 
pvm 七 a message say'i^ 
parity >/as atu^itd a^d 

"tKc matWmc s s*ba*be 七。 
-tKc ttas^iAavtcv-S-ta-tc- 


public void insertQuarter() { 

System, out .println (''You inserted a quarter"); 

gumballMachine.setState(gumballMachine.getHasQuarterState()); / , 

} 汉一 / You II sec how these 

- / wovk ih just a scd... 

public void ejectQuarter() { 

System, out .println (''You haven't inserted a quarter"); _ . , 

} ~ '七 七 moy ' c V 

badk i-f y ou y>cvcv ' 5 avc 

public void turnCrank () { 1-b -to us| 

System, out .println (''You turned, but there's no quarter"); 


public void dispense() { 

System, out .println (''You need to pay first ’’）； 

} 


A^d, you dah ； t get a gumball 
i*P you dov\t pay us. 

I/Ve ca^t be dispchs'm^ 
gumballs without payment 
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state objects in the gumball machine 


Reworking the Gumball Machine 

before we finish the State classes, weVe going to rework the Gumball Machine - that way 
you can see how it all fits togethei: We'll start with the state-related instance variables 
and switch the code from using integers to using state objects: 
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Now, let's look at the complete ^umballMachine class. 


public class GumballMachine { 

State soldOutState; 

State noQuarterState; 
State hasQuarterStated- 
State soldState; 






are all ^Stales a— … 

...a^d State mstandc variable- 


state state = soldOutState; 


int count 


0; 


public GumballMachine(int numberGumballs) { 
soldOutState = new SoldOutState(this); 
noQuarterState = new NoQuarterState(this); 
hasQuarterState = new HasQuarterState(this) 
soldState = new SoldState(this); 
this.count = numberGumballs; 
if (numberGumballs >0) { 
state = noQuarterState; 

} 

} 


public void insertQuarter() 
state.insertQuarter(); 

} 


public void ejectQuarter() 
state.ejectQuarter(); 

} 

public void turnCrank() { 

state.turnCrank(); 
state.dispense(); 

} 



The touh-t ms-ta«ie vaviable holds 
■the touni o-f gumballs - ihitially the 
is empty. 

I 七 also Creates Slate 

• m s*ta^cs, 01 .C O-f tatw 

^ "thcv-c 3\rc move tholh O 
jumballs WC sci the s-ta-tc io the 
Wo 公 u^rte\rS'tatc. 

p We 


Kojs wc do / 七 heed a 的 

atiion method -fov dispc^scO *m 
^umballMa^'me because jus 七 a 於 
m-tcv^al a^tiem; a user tar!{, ask 七 he 
io dispense div-cdily. Bu-t wc 
do ^alI dispc^scO oy\ -tKc S-ta-tc object 
-fyom 七 umGrahkO 


void setState(State state) 
this.state = state; 

} 


This method allov/s o-t^cv- objc^'U (like 
ouv- State objects) to -tva^si-tio^ 
io a di-f-fcv-c^-t s-ta-tc- 

void releaseBall () { 

System.out .println (''A gumball comes rolling out the slot •••〃）； 
if (count != 0) { 

count = count - 1; The rwa^hihC suppo\rts a vcIcascBallO 

hclpcv rwethod releases -the ball ar\d 
dcdvcrwchts the 乙 ou»vt ihstah^c variable* 

// More methods here including getters for each State... 

This mdudes rwethods like gc-tNo^ua\r-tc\rS-ta*tcO -for gc-ttmg cath 
七 e objed - t , dr>d gc * tCour\-tO -for ybtmg the gumball doutvt . 
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more states for the gumball machine 


Implementing more states 

Now that you’re starting to get a feel for how the Gumball Machine and the states 
fit together, let’s implement the HasQuarterState and the SoldState classes... 


.，… D ， 


I 


public class HasQuarterState implements State { 

GumballMachine gumballMachine; 

public HasQuarterState(GumballMachine gumballMachine) { 
this.gumballMachine = gumballMachine; 

} 

public void insertQuarter() { 

System, out .println (''You can't insert another quarter" 

} 


public void ejectQuarter() { 

System, out.println (''Quarter returned"); 

gumballMachine.setState(gumballMachine.getNoQuarterState()); 

} 

public void turnCrank() { 

System, out.println (''You turned 

gumballMachine.setState(gumballMachine.getSoldState()). 

} 

public void dispense() { 

System, out .println (''No gumball dispensed"); 

} 


„ yass .t \ 代 ^ 1$ J 


\^°1 

state- 


0 


or 


t ㈣ 

state- 

Quavtcv a^d 

"to 

Ko6^^v-*tcv-S*t3*tc- 

灼七 he dva 灼 k »s 

-turned >/c 

madWrnc -to *tV\c 
SoldS-ta-tc sla-tc by 
dallm^ sctSta 七 c() 

me 七 W ad \>assm^ \i 
七 k SoIdSlatc obj^t 
TKc SoldS-ta-tc o^tti 
•is vc-tvicvcd W *tV\c 
ytSoldS*t3*tcC) 
ybtev method 
(*b^cvc or\t o-f *t^csc 
mc-tKods ^ov 
eddV\ s*ta*tc)- 
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Now, let’s check out the SoldState class... 

public class SoldState implements State { 

// constructor and instance variables here 

public void insertQuarter() { 

System, out .printIn (''Please wait, we^ re 

} 

public void ejectQuarter () { 

System, out .printIn (''Sorry, you already 

} 



public void turnCrank() { 

System, out .println (''Turning twice doesn't get you another gumball \ ,r ); 

} 


public void dispense() { 

gumballMachine.releaseBall() ; ■ 

if (gumballMachine.getCount() > 0) 

gumballMachine.setState(gumballMachir^ .getNoQuarterState()); 
} else { 

System, out .println (''Oops, out of g^ffnballs \ "); 
gumballMachine. setState (gumball^chine. getSoldOutState ()); 

} 


代 a 、work W—... 




:心二 — a '、. 







Look back at the GumballMachine implementation. If the crank is turned and not successful (say 
the customer didn’t insert a quarter first), we call dispense anyway, even though it’s unnecessary. 
How might you fix this? 


you are here ► 405 





your turn to implement a state 


We have one remaining class we haven’t implemented: SoldOutState. 
Why don’t you implement it? To do this, carefully think through how 
the Gumball Machine should behave in each situation. Check your 
answer before moving on... 


public class SoldOutState implements { 

GumballMachine gumballMachine; 

public SoldOutState(GumballMachine gumballMachine) { 


public void insertQuarter() { 


public void ejectQuarter() { 


public void turnCrank() { 


咬考 rpen your pencil 


public void dispense() { 
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the state pattern 


Let's take a look at what weVe done so far:.. 

For starters, you now have a Gumball Machine implementation that is structural^ quite different from your 
first version, and yet functionally it is exactly the same. By structurally changing the implemention you’ve: 

■ Localized the behavior of each state into its own class. 

■ Removed all the troublesome if statements that would have been difficult to maintain. 

■ Closed each state for modification, and yet left the Gumball Machine open to extension by 
adding new state classes (and we’ll do this in a second). 

■ Created a code base and class structure that maps much more closely to the Mighty Gumball 
diagram and is easier to read and understand. 

Now let’s look a little more at the functional aspect of what we did: 


eat 


^_ball Muhins States 


■ 



current state 


n- 






The duvvctvt o-f 

c>oia 
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■Ucsc dlass 
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state transitions 
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^mb^ll Machine States 


turnCrank() 


turnCrankQ 
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current state 



⑭ 


TRANSITION to SOLD state 
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^uMlM^chi^SUtes 


dispenseQ 


» 



wore 
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ma^liihe will 
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the state pattern 


Sharpen your pencil 


Beliind the Scenes : 
Self-Guided Tour 


Trace the steps of the Gumball Machine starting with the NoQuarter state. Also annotate the diagram with actions 
and output of the machine. For this exercise you can assume there are plenty of gumballs in the machine. 
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state pattern defined 


The State Pattern defined 

Yes, it’s true, we just implemented the State Pattern! So now, let’s take a look at what it’s all about: 


The State Pattern allows an object to alter its behavior 
when its internal state changes. The object will appear to 
change its class. 


The first part of this description makes a lot of sense, right? Because the pattern encapsulates state into 
separate classes and delegates to the object representing the current state, we know that behavior changes 
along with the internal state. The Gumball Machine provides a good example: when the gumball machine 
is in the NoQuarterState and you insert a quarter, you get different behavior (the machine accepts the 
quarter) than if you insert a quarter when it’s in the Has Quarter State (the machine rejects the quarter). 

What about the second part of the definition? What does it mean for an object to “appear to change its 
class?” Think about it from the perspective of a client: if an object you’re using can completely change its 
behavior, then it appears to you that the object is actually instantiated from another class. In reality, however, 
you know that we are using composition to give the appearance of a class change by simply referencing 
different state objects. 

Okay, now it’s time to check out the State Pattern class diagram: 


TKc Co^i is i\>t tlass tha 七 
d ” uwbcv of m*tcv-r\al 
s-t3*tcs. \y\ ouv ttc 

今 umballMaAmc is 栋 c 



dc-Pmcs a dommoh 
(or all siaics; the 

siaics all implcmcirt -the same irvtcv 心 dc, 
So iivtcvdKahgcablc. 
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the state pattern 



Wait a sec, 
from what I remember 
of the Strategy Pattern, 
this class diagram is 
EXACTLY the same. 


You’ve got a good eye! Yes, the class diagrams are essentially the 
same, but the two patterns differ in their intent. 

With the State Pattern, we have a set of behaviors encapsulated in 
state objects; at any time the context is delegating to one of those 
states. Over time, the current state changes across the set of state 
objects to reflect the internal state of the context, so the context’s 
behavior changes over time as well. The client usually knows very 
little, if anything, about the state objects. 


With Strategy, the client usually specifies the strategy object that 
the context is composed with. Now, while the pattern provides the 
flexibility to change the strategy object at runtime, often there is a 
strategy object that is most appropriate for a context object. For 
instance, in Chapter 1, some of our ducks were configured to fly 
with typical flying behavior (like mallard ducks), while others were 
configured with a fly behavior that kept them grounded (like rubber 
ducks and decoy ducks). 


In general, think of the Strategy Pattern as a flexible alternative to 
subclassing; if you use inheritance to define the behavior of a class, 
then you’re stuck with that behavior even if you need to change it. 
With Strategy you can change the behavior by composing with a 
different object. 


Think of the State Pattern as an alternative to putting lots of 
conditionals in your context; by encapsulating the behaviors within 
state objects, you can simply change the state object in context to 
change its behavior. 
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q&a about the state pattern 


tfeeret^re np 

)umb Quc 


In the GumballMachine, the states decide 
what the next state should be. Do the ConcreteStates 
always decide what state to go to next? 


r\l No, not always. The alternative is to let the Context 
decide on the flow of state transitions. 

As a general guideline, when the state transitions are fixed 
they are appropriate for putting in the Context; however, 
when the transitions are more dynamic, they are typically 
placed in the state classes themselves (for instance, in the 
GumballMachine the choice of the transition to NoQuarter or 
SoldOut depended on the runtime count of gumballs). 

The disadvantage of having state transitions in the state 
classes is that we create dependencies between the state 
classes. In our implementation of the GumballMachine 
we tried to minimize this by using getter methods on the 
Context, rather than hardcoding explicit concrete state 
classes. 

Notice that by making this decision, you are making a 
decision as to which classes are closed for modification 
- the Context or the state classes - as the system evolves. 

Do clients ever interact directly with the 

states? 

No. The states are used by the Context to 
represent its internal state and behavior, so all requests 
to the states come from the Context. Clients don’t directly 
change the state of the Context. It is the Context’s job 
to oversee its state, and you don’t usually want a client 
changing the state of a Context without that Context’s 
knowledge. 

If I have lots of instances of the Context in my 
application, is it possible to share the state objects 
across them? 


Yes, absolutely, and in fact this is a very common 
scenario. The only requirement is that your state objects do 
not keep their own internal state; otherwise, you’d need a 
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To share your states, you’ll typically assign each state to a 
static instance variable. If your state needs to make use of 
methods or instance variables in your Context, you’ll also 
have to give it a reference to the Context in each handler() 
method. 


It seems like using the State Pattern always 
increases the number of classes in our designs. Look 
how many more classes our GumballMachine had 
than the original design! 

You’re right, by encapsulating state behavior 
into separate state classes, you’ll always end up with 
more classes in your design. That’s often the price you 
pay for flexibility. Unless your code is some “one off 
implementation you’re going to throw away (yeah, right), 
consider building it with the additional classes and you’ll 
probably thank yourself down the road. Note that often 
what is important is the number of classes that you expose 
to your clients, and there are ways to hide these extra 
classes from your clients (say, by declaring them package 
visible). 

Also, consider the alternative: if you have an application 
that has a lot of state and you decide not to use separate 
objects, you’ll instead end up with very large, monolithic 
conditional statements. This makes your code hard to 
maintain and understand. By using objects, you make 
states explicit and reduce the effort needed to understand 
and maintain your code. 

The State Pattern class diagram shows 
that State is an abstract class. But didn’t you use 
an interface in the implementation of the gumball 
machine’s state? 


Yes. Given we had no common functionality to 
put into an abstract class, we went with an interface. In 
your own implementation, you might want to consider an 
abstract class. Doing so has the benefit of allowing you to 
add methods to the abstract class later, without breaking the 
concrete state implementations. 



the state pattern 


We still need to finish the &umball 1 m 10 game 

Remember, we’re not done yet. We’ve got a game to implement; but now that we’ve got the State 
Pattern implemented, it should be a breeze. First, we need to add a state to the GumballMachine class: 

public class GumballMachine { 

State soldOutState; 

State noQuarterState; 

State hasQuarterState 
State soldState; 

State winnerState; 4 


Po^t -fov-gc-t you also 
-bo add a yiicr method -fov- 
-too. 



I\\\ you -to add *«s i\\t 
•，- 1 m i\\t to^br\Atb>r. 


Now let’s implement the WinnerState class itself, it’s remarkably similar to the SoldState class: 


public class WinnerState implements State { 


// instance variables and constructor 


// insertQuarter error message 
// ejectQuarter error message 


// turnCrank error message 



Just SoldState 


Heve v/e vclcasc tv/o gumbalU 如 ” 

90 -to or -tKc 

SoldOu-tSta-tc. 


public void dispense() { 

System, out .println (''YOU^ RE A WINNER! You get two gumballs for your quarter"); 
gumballMachine.releaseBall(); 
if (gumballMachine.getCount() == 0) { 

gumballMachine.setState(gumballMachine.getSoldOutState()); 

} else { ^ 

gumballMachine . releaseBall () ; < ^' s as v/c 

if (gumballMachine. getCount () > 0) { d sc£-ov\di 

gumballMachine. setState (gumballMachine. getNoQuar ter State () ) ; gur^ball 

} else { v-clcasc it 

System, out .print In (''Oops, out of gumballs!"); 
gumballMachine.setState(gumballMachine.getSoldOutState()); 

} 
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implementing the 1 in 10 game 

Finishing the game 


We’ve just got one more change to make: we need to implement the random 
chance game and add a transition to the WinnerState. We’re going to add both to 
the HasQuarterState since that is where the customer turns the crank: 


public class HasQuarterState implements State { 

Random randomWinner = new Random(System.currentTimeMillis()); 
GumballMachine gumballMachine; 

public HasQuarterState(GumballMachine gumballMachine) { 
this.gumballMachine = gumballMachine; 

} 


add a 

v-andow yWAwbcv 
tV«ante wiwi 吒 ... 


public void insertQuarter() { 

System, out .println (''You can^ t insert another quarter"); 

} 


public void ejectQuarter() { 

System, out .println (''Quarter returned"); 

gumballMachine.setState(gumballMachine.getNoQuarterState() 

} 


"."the 的 v/c dc-tcvmmc 

i-f "tWis dus-tomcv v/o 灼 . 


public void turnCrank() { 

System, out .println (''You turned. . •’’）； 
int winner = randomWinner.nextlnt(10); 

if ((winner == 0) && (gumballMachine.getCount() >1)) { 

gumballMachine.setState(gumballMachine.getWinnerState()); 
} else { 

gumballMachine.setState(gumballMachine.getSoldState()); 

} 

} 

public void dispense() { 

System. out. println (''No gumball dispensed"); 

} 


V 


If they woh, dhd 
chough gurwballs Ic-ft -for 
to get "two, yjc 
3。 to the lA/ihhCvS-tatc ； 
othciry/isc, v/c go to 七 he 
SoldStatc (just like v/c 
always did). 


Wow, that was pretty simple to implement! We just added a new state to the GumballMachine 
and then implemented it. All we had to do from there was to implement our chance game and 
transition to the correct state. It looks like our new code strategy is paying off... 
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the state pattern 


Vmo for the CEO of Mighty &umball \m. 


The CEO of Mighty Gumball has dropped by for a demo of your new gumball game code. Let’s 
hope those states are all in order! We’ll keep the demo short and sweet (the short attention span of 
CEOs is well documented), but hopefully long enough so that we’ll win at least once. 




public class GumballMachineTestDrive { 

public static void main(String[] args) { 

GumballMachine gumballMachine = new GumballMachine(5); 


Oy\U, ^\y\, s-tav-t a gumball 
f-"" v/i 七。 ^umballs. 


System.out.printIn(gumballMachine); 

gumballMachine.insertQuarter(); 
gumballMachine.turnCrank(); 

System.out.printIn(gumballMachine); 

gumballMachine.insertQuarter(); 
gumballMachine.turnCrank(); 
gumballMachine.insertQuarter(); 
gumballMachine.turnCrank(); 



1/Vc "to yt a state, 

so we \us-b keep "those 

3 >r\di Oc lA/c 

fvm-t ou-t i\\t s-tatc gumball 

mad^'rne cvcvy SO 


System.out.println(gumballMachine); 


} 



w ls ；o t 

des.，is — 吒七 0 屮。木 . 
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testing the gumball machine 



㈡ 二 總 


Y/\^3*b? 
… c 


I File Edit Window Help Whenisagumballajawbreaker? | 


% java GumballMachineTestDrive 
Mighty Gumball, Inc• 

Java-enabled Standing Gumball Model #2004 

Inventory : 5 gumballs 

Machine is waiting for quarter 

You inserted a quarter 
You turned... 

YOU^RE A WINNER! You get two gumballs for your quarter 
A gumball comes rolling out the slot... 

A gumball comes rolling out the slot... 

Mighty Gumball, Inc. 

Java-enabled Standing Gumball Model #2004 

Inventory : 3 gumballs 

Machine is waiting for quarter 

You inserted a quarter 
You turned... 

A gumball comes rolling out the slot... 

You inserted a quarter 
You turned... 

YOU'RE A WINNER! You get two gumballs for your quarter 
A gumball comes rolling out the slot... 

A gumball comes rolling out the slot... 

Oops, out of gumballs! 

Mighty Gumball, Inc• 

Java-enabled Standing Gumball Model #2004 
Inventory : 0 gumballs 
Machine is sold out 

% 


D 


tfcere|£ire np 

>umb Questions 


Why do we need the WinnerState? Couldn’t we just have the SoldState dispense two gumballs? 


That’s a great question. SoldState and WinnerState are almost identical, except that WinnerState dispenses two 
gumballs instead of one. You certainly could put the code to dispense two gumballs into the SoldState. The downside 
is, of course, that now you’ve got TWO states represented in one State class: the state in which you’re a winner, and the 
state in which you’re not. So you are sacrificing clarity in your State class to reduce code duplication. Another thing to 
consider is the principle you learned in the previous chapter: One class, One responsibility. By putting the WinnerState 
responsibility into the SoldState, you’ve just given the SoldState TWO responsibilities. What happens when the 
promotion ends? Or the stakes of the contest change? So, it’s a tradeoff and comes down to a design decision. 
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the state pattern 


Bravo! Great job, 
gang. Our sales are already going 
through the roof with the new game. 
You know, we also make soda machines, 
and I was thinking we could put one of 
those slot machine arms on the side and 
make that a game too. We've got four 
year olds gambling with the gumball 
machines; why stop there? 


Sanity check... 

Yes, the CEO of Mighty Gumball probably needs a sanity check, but that’s 
not what we’re talking about here. Let’s think through some aspects of the 
GumballMachine that we might want to shore up before we ship the gold version: 



We’ve got a lot of duplicate code in the Sold and Winning 
states and we might want to clean those up. How would we 
do it? We could make State into an abstract class and build in 


some default behavior for the methods; after all, error messages 
like, “You already inserted a quarter，’’ aren’t going to be seen 
by the customer. So all “error response” behavior could be 
generic and inherited from the abstract State class. 


pawwVt 
|m a y 山 11 
乙 Wme ， ⑽七 


a 


The dispenseO method always gets called, even if the crank is 
turned when there is no quarter. While the machine operates 
correctly and doesn’t dispense unless it’s in the right state, we 
could easily fix this by having turnCrankO return a boolean, 
or by introducing exceptions. Which do you think is a better 


solution? 


All of the intelligence for the state transitions is in the State 
classes. What problems might this cause? Would we want to 
move that logic into the Gumball Machine? What would be 
the advantages and disadvantages of that? 

Will you be instantiating a lot of GumballMachine objects? 
If so, you may want to move the state instances into static 
instance variables and share them. What changes would this 
require to the GumballMachine and the States? 
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fireside chats: state and strategy 


Fireside Chats 



Tonight ： A Strategy and State Pattern Reunion. 


Strategy 


State 


Hey bro. Did you hear I was in Chapter 1? 


Yeah, word is definitely getting around. 


I was just over giving the Template Method guys a 
hand — they needed me to help them finish off their 
chapter. So, anyway, what is my noble brother up 
to? 

Same as always — helping classes to exhibit different 
behaviors in different states. 

I don’t know, you always sound like you’ve just 
copied what I do and you’re using different words 
to describe it. Think about it: I allow objects to 
incorporate different behaviors or algorithms 
through composition and delegation. You’re just 
copying me. 

I admit that what we do is definitely related, but my 
intent is totally different than yours. And, the way I 
teach my clients to use composition and delegation 
is totally different. 

Oh yeah? How so? I don’t get it. 

Well if you spent a little more time thinking about 
something other yourself, you might. Anyway, 
think about how you work: you have a class you’re 
instantiating and you usually give it a strategy 
object that implements some behavior. Like, in 
Chapter 1 you were handing out quack behaviors, 
right? Real ducks got a real quack, rubber ducks 
got a quack that squeaked. 

Yeah, that was some fine work... and I’m sure you 
can see how that’s more powerful than inheriting 

your behavior, right? Yes, of course. Now，think about how I work; it’s 

totally different. 

Sorry, you’re going to have to explain that. 
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the state pattern 


Strategy 


Hey, come on, I can change behavior at runtime 
too; that’s what composition is all about! 


Well, I admit, I don’t encourage my objects to have 
a well-defined set of transitions between states. In 
fact, I typically like to control what strategy my 
objects are using. 


State 

Okay，when my Context objects get created, I may 
tell them the state to start in, but then they change 
their own state over time. 


Sure you can, but the way I work is built around 
discrete states; my Context objects change state 
over time according to some well defined state 
transitions. In other words, changing behavior is 
built in to my scheme — it’s how I work! 


Look, we’ve already said we’re alike in structure, but 
what we do is quite different in intent. Face it, the 
world has uses for both of us. 


Yeah, yeah, keep living your pipe dreams brother. 
You act like you’re a big pattern like me, but check 
it out: I’m in Chapter 1; they stuck you way out in 
Chapter 10. I mean, how many people are actually 
going to read this far? 


Are you kidding? This is a Head First book and 
Head First readers rock. Of course they’re going to 
get to Chapter 10! 


That’s my brother, always the dreamer. 
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Chapter 10 


refill exercise 

We almost forgot! 



the state pattern 


e^arpen your pencil 

\ 〜 We nee 


We need you to write the refill() 


method for the Gumball machine. It has one 


argument - the number of gumballs you’re adding to the machine - and should 
update the gumball machine count and reset the machine's state. 
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who does what? 
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the state pattern 




< Tools for your design Toolbox 

It’s the end of another chapter; you’ve got enough 
patterns here to breeze through any job interview! 
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BULLET POINTS 


■ The State Pattern allows an 
object to have many different 
behaviors that are based on its 
internal state. 

■ Unlike a procedural state 
machine, the State Pattern 
represents state as a full-blown 
class. 

■ The Context gets its behavior 
by delegating to the current 
state object it is composed 
with. 

■ By encapsulating each state 
into a class, we localize any 
changes that will need to be 
made. 

■ The State and Strategy 
Patterns have the same class 
diagram, but they differ in 
intent. 

■ Strategy Pattern typically 
configures Context classes 
with a behavior or algorithm. 

■ State Pattern allows a Context 
to change its behavior as the 
state of the Context changes. 

■ State transitions can be 
controlled by the State classes 
or by the Context classes. 

■ Using the State Pattern will 
typically result in a greater 
number of classes in your 
design. 

■ State classes may be shared 
among Context instances. 
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exercise solutions 

Exercise solutions 
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the state pattern 


Based on our first implementation, which oi the iollowing apply? 
(Choose all that apply.) 


This code certainly isn’t adhering to the 
Open Closed Principle! 

This code would make a FORTRAN 
programmer proud. 

This design isn’t even very object 
oriented. 


’C. State transitions aren’t explicit; they 


□f 7 D. 
I^E. 


are buried in the middle of a bunch of 
conditional code. 

We haven’t encapsulated anything that 
varies here. 

Further additions are likely to cause bugs 
in working code. 



Exercise solutions 


Sharpen your pencil 


Sharpen your pi 


lencil 


We have one remaining class we haven’t implemented: SoldOutState. 
Why don't you implement it? To do this, carefully think through how 
the Gumball Machine should behave in each situation. Check your 
answer before moving on... 


public class SoldOutState implements State { 
GumballMachine gumballMachine; 


LU- SOWCO^C 

丄 Matwmc . 


public SoldOutState(GumballMachine gumballMachine) { 
this.gumballMachine = gumballMachine; 

} 

public void insertQuarter() { 

System.out.printIn(''You can f t insert a quarter, the machine is sold out"); 

} 

public void ejectQuarter () { 

System.out.printIn(''You can’t eject, you haven't inserted a quarter yet"); 

} 

public void turnCrank() { 

System. out. print In (''You turned, but there are no gumballs"); 


public void dispense() { 

System. out. print In (''No gumball dispensed"); 




B. c 


} 


} 
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exercise solutions 


7: Sharpen your pencil 


To implement the states, we first need to define what the behavior will be 
when the corresponding action is called. Annotate the diagram below with the 
behavior of each action in each class; we’ve already filled in a few for you. 


6 \o io Has6Juav-tcv-S-ta-tc 

丁 ell tKc dus-fcomcv ''you ihsev-ted a ^uav-tcv w 

丁 cl I 七 he dus-fcomcv- “you -tuv-hcd, bu 七七 heve’s ho <\uav-tcv ，; 
Tell -the dus-tomcv “you y\ccd io pay -fivs-t w _ 




NoQuarterState 

insertQuarter() 

ejectQuarter() 

turnCrank() 

dispense() 


Tdl -tKc dus-fcomcv- “you 6 扣’七 msevt a^o-tKcv 

与 ive badk quarter, 30 io No ^uavtcr s-fcatc _ 

(\o io SoldS-tatc - ---- 

Tell "tKc dus"tomcv, w ^o gumball dispensed”_ 



HasQuarterState 

insertQuarter() 

ejectQuarter() 

turnCrank() 

dispense() 


丁 ell dus*tomc\r please wait, v/cVc already jiv'mj you a gum ball 

丁 cl I the dus-tomcv w sor\ry, you already Whcd the tra^k 1 

丁 cl I the dus-tomc\r ''tuvhihj tv/idc doesn'-t get you aho-tKcv- ^umbair ； 

Dispense one jumbalI. CKcdk hurwbev o-f gumballs ； i-f > O, go 
■to Muair-tcr s-ta-tc, otKcvwisc, go -to Sold Out state 



SoldState 

insertQuarter() 

ejectQuarter() 

turnCrank() 

dispense() 


丁 cl I "the dus-fcomcv- W -tKc md^KihC is sold ou*t" 

Tdl -the dus-feomcv “you haven't ihsev-ted a ^uavtcv yc*t w 
丁 el I the dusiomcv m TKcvc av-c v\o jumbal ls^ 

Tdl 七 he dus-tomcv U ho ^umbdll dispensed" 



SoldOutState 

insertQuarter() 

ejectQuarter() 

turnCrank() 

dispense 。 


Tell ihe dus-tomcv w flcasc y/ait, wcVc alv-cady ^ivihj you a jumbalr ； 
丁 cl I the dus-tomc\r M so\rvy, you already tuv-hcd iKc dvahk w 



Tell the dus-fcomcv ''-tuvh'mg iW\u doesn't gei you aho-tKcv- jumball ;； 

Dispense *two Jumballs. Chcdk humbev- o( gumballs ； i-f > O, 

3。 to Hosier s-ta-tc ； o-tKcv-y/isc, go to SoldOu-tStatc 


WinnerState 

insertQuarter() 

ejectQuarter() 

turnCrank() 

dispense() 
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the state pattern 


dele^aies £ 0 



siaie ' 


insertQuarterO 


insertQuarter() 


Whihe 把 £i 0h 


Beliind ihe Scenes: 
Self-Guided Tour 
Solution 




■brahsiticms *bo 
ttas<$ua\ric\r staic 




■bv'a^si-biohs "to 
Sold s-taic 



^umbsll Machine States 


ttcvc *thc 

^ivcs ou-t a jumbal I 
by 七 “e "m-tc\rr\al 

dispcr\scO at"tior\. 



"to No6^ua\r-tcv 
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exercise solutions 







We need you to write the refillf) method for the Gumball machine. It has one 
argument, the number of gumballs you’re adding to the machine, and should 
update the gumball machine count and reset the machine’s state. 


void refill (int count) { 
this.count = count; 
state = noOuarterState; 
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11 the YrQxy Pattern 

Controlling + 

♦ Object Access ^ 



Ever play good cop, bad cop? You’re the good cop and you provide all your 
services in a nice and friendly manner, but you don’t want everyone asking you for services, 
so you have the bad cop control access to you. That’s what proxies do: control and manage 
access. As you’re going to see, there are lots of ways in which proxies stand in for the 
objects they proxy. Proxies have been known to haul entire method calls over the Internet for 
their proxied objects; they’ve also been known to patiently stand in the place for some pretty 
lazy objects. 


this is a new chapter 
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whafs the goal 



Rc^cr^bcv the CBO o( 

“ball, 


'' / ^Heyteam^ I’d 
really like to get 
some better monitoring for 
my gumball machines. Can you 
find a way to get me a report of 
inventory and machine state? 


Sounds easy enough. If you remember, we’ve already 
got methods in the gumball machine code for getting the 
count of gumballs (getCountO), and getting the current 
state of the machine (getStateO). 

All we need to do is create a report that can be printed out 
and sent back to the CEO. Hmmm，we should probably 
add a location field to each gumball machine as well; that 
way the CEO can keep the machines straight. 

Let’s just jump in and code this. We’ll impress the CEO 
with a very fast turnaround. 
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the proxy pattern 


Coding the Monitor 


Let’s start by adding support to the GumballMachine class so that it 
can handle locations: 


public class GumballMachine { 

// other instance variables 
String location; 



A lotatioh isjusia Stv-i h g. 


public GumballMachine(String location, int count) { 
// other constructor code here 
this.location = location; 

} 


public String getLocation() 
return location; 

} 

// other methods here 




is passed ih-to -the 

stoved ih the 


Let's also add a mrtW 七。 

^vab -b^c lodat»o^ wed it 


Now let’s create another class, GumballMonitor, that retrieves the machine’s 
location, inventory of gumballs and the current machine state and prints them 
in a nice little report: 


public class GumballMonitor { 

GumballMachine machine; 

public GumballMonitor(GumballMachine machine) { 
this.machine = machine; 

} 



Thc 厂 0 hi 七饮 the ih its 

ahd assign it io -the 
啪心⑽ ihs-b h ^ c vav-iable. 


} 


public void report() { 

System, out .println (''Gumball Machine : '' + machine.getLocation ()); 
System.out.println (''Current inventory: '' + machine.getCount () + ' 
System, out .println (''Current state : '、+ machine. getState ()); 

} 


gumballs"); 
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local gumball monitor 


Testing the Monitor 

We implemented that in no time. The CEO is going to be thrilled and amazed by our 
development skills. 

Now we just need to instantiate a GumballMonitor and give it a machine to monitor: 


public class GumballMachineTestDrive { 

public static void main(String[] args) { 
int count = 0; 

if (args.length < 2) { 

System, out .printIn (''GumballMachine 
System.exit(1); 


count = Integer.parselnt(args[1]); 


pass in a \otahoY\ av\d mi-tial # o-f 
^^ ^umballs OY\ 6ommay>d 1’mc. 

<name> <inventory>") ; — 、 Do: 七 -foirge-t io give 
f 仏 C 乙 OhS*bru 乙 tov a 
I lo^atioh 匕 ouht.” 


GumballMachine gumballMachine = new GumballMachine(args[0], count); 


GumballMonitor monitor = new GumballMonitor(gumballMachine); 


// rest of test code here 
monitor.report(); 

个 1/Vb v/c r\ttA a vcforb ov\ 

v/c tall 

v~epov ■ 七 ( ） w'C'b^od- 


又 … and msta^iate a »>or,iW ar>d \>ass it a 

w adWme to provide a or,- 

I File Edit Window Help FlyingFish | 


% java GumballMachineTestDrive Seattle 112 

Gumball Machine : Seattle 
Current Inventory: 112 gumballs 
Current State: waiting for quarter 
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Frank: Remote proxy. Think about it: we’ve already got the monitor code written, right? We give the 
GumballMonitor a reference to a machine and it gives us a report. The problem is that monitor runs 
in the same JVM as the gumball machine and the CEO wants to sit at his desk and remotely monitor the 
machines! So what if we left our GumballMonitor class as is, but handed it a proxy to a remote object? 

Joe ： I’m not sure I get it. 

Jim ： Me neither. 

Frank: Let’s start at the beginning... a proxy is a stand in for a real object. In this case, the proxy acts 
just like it is a Gumball Machine object, but behind the scenes it is communicating over the network to 
talk to the real, remote GumballMachine. 

Jim ： So you’re saying we keep our code as it is, and we give the monitor a reference to a proxy version 
of the GumballMachine... 


Joe ： And this proxy pretends it’s the real object, but it’s really just communicating over the net to the 
real object. 

Frank: Yeah, that’s pretty much the story. 

Joe ： It sounds like something that is easier said than done. 

Frank: Perhaps, but I don’t think it’ll be that bad. We have to make sure that the gumball machine 
can act as a service and accept requests over the network; we also need to give our monitor a way to get 
a reference to a proxy object, but we’ve got some great tools already built into Java to help us. Let’s talk 
a little more about remote proxies first... 
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remote proxy 


The role of the Vemote proxy' 

A remote proxy acts as a local representative to a remote object. What’s a “remote 
object?” It’s an object that lives in the heap of a different Java Virtual Machine 
(or more generally, a remote object that is running in a different address space). 
What’s a “local representative?” It’s an object that you can call local methods on 
and have them forwarded on to the remote object. 



Your client object acts like it’s making remote method calls. 
But wte it’s really doing is calling mediods on a Keap- 
local "prox/ object that Kandles all flie low-level details of 
network communication. 
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the proxy pattern 


This is a pretty slick idea. Were 
going to write some code that takes a 
method invocation, somehow transfers it over 
the network and invokes the same method on a 
remote object. Then I presume when the call is 
complete, the result gets sent back over the 
network to our client. But it seems to me 
this code is going to be very 
tricky to write. 



Hold on now, we 
aren't going to write that code 
ourselves, it’s pretty much built 
into Java's remote invocation 
functionality. All we have to do 
is retrofit our code so that it 
takes advantage of RMI. 


Before going further, think about how you’d design a system to enable remote method invocation. 
How would you make it easy on the developer so that she has to write as little code as possible? 
How would you make the remote invocation look seamless? 




Should making remote calls be totally transparent? Is that a good idea? What might be a problem 
with that approach? 
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RMI detour 


Adding a remote proxy to the &u 晰 ball 
Machine moHitoring code 

On paper this looks good, but how do we create a proxy that knows how to invoke a method on an 
object that lives in another JVM? 

Hmmm. Well, you can’t get a reference to something on another heap, right? In other words, you 
can’t say: 


Duck d = <object in another heap> 

Whatever the variable d is referencing must be in the same heap space as the code running the 
statement. So how do we approach this? Well, that’s where Java’s Remote Method Invocation 
comes in... RMI gives us a way to find objects in a remote JVM and allows us to invoke their 
methods. 

You may have encountered RMI in Head First Java; if not, we’re going to take a slight detour and 
come up to speed on RMI before adding the proxy support to the Gumball Machine code. 

So, here’s what we’re going to do: 


❶ First, we’re going to take the RMI 
Detour and check RMI out. Even if 
you are familiar with RMI, you might 
want to follow along and check out the 
scenery. 

❾ Then we’re going to take our 

GumballMachine and make it a remote 
service that provides a set of methods 
calls that can be invoked remotely. 

❾ Then, we going to create a proxy that can 
talk to a remote GumballMachine, again 
using RMI, and put the monitoring system 
back together so that the CEO can monitor 
any number of remote machines. 







RMI Detour 


If you're new to RMI, 
take the detour that runs 
over the next few pages; 
otherwise, you might want to 
just quickly thumb through 
the detour as a review. 
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Remote methods 101 

Let’s say we want to design a system that allows us to call a local object that forwards each 
request to a remote object. How would we design it? We’d need a couple of helper objects 
that actually do the communicating for us. The helpers make it possible for the client to 
act as though it’s calling a method on a local object (which in fact, it is). The client calls a 
method on the client helper, as if the client helper were the actual service. The client helper 
then takes care of forwarding that request for us. 

In other words, the client object thinks it’s calling a method on the remote service, because 
the client helper is pretending to be the service object. Pretending to be the thing with the 
method the client wants to call. 



But the client helper isn’t really the remote service. Although the client helper acts like it 
(because it has the same method that the service is advertising), the client helper doesn’t 
have any of the actual method logic the client is expecting. Instead, the client helper 
contacts the server, transfers information about the method call (e.g., name of the method, 
arguments, etc.), and waits for a return from the server. 

On the server side, the service helper receives the request from the client helper (through 
a Socket connection), unpacks the information about the call, and then invokes the real 
method on the real service object. So, to the service object, the call is local. It’s coming from 
the service helper, not a remote client. 

The service helper gets the return value from the service, packs it up, and ships it back (over 
a Socket’s output stream) to the client helper. The client helper unpacks the information 
and returns the value to the client object. 


TW.S S^ld look W‘.. 


ii's 七 。广 

Real It 

tWmks 七 

仔 aUa" 

do veal 糾以 ’ 


|r| Client heap 


c 以一叶七 

Real TWm^- 



TW.s \s 0,O'«0| 
七 。 be w 


Server heap 






Seirvide helpev gets the 
k the died 
helpev, uhpatks i-fc, 3 hd 
Wlls -the me-thod on the 
Real Sewide ， 
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remote method invocation 


How the method call happens 



② Client helper packages up information about the call 
(arguments, method name, etc.) and ships it over the 



③ Service helper unpacks the information from the client helper, 
finds out which method to call (and on which object) and 
invokes the real method on the real service object. 


jD] Clien+ hea P ''client wants to call a method" 


doBigThingQ 


Server heap 

- 

doBigThingQ 


QO 

■/,-m 



1 。妒. TV>e 
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the proxy pattern 



⑤ Service helper packages up information returned from the 
call and ships it back over the network to the client helper. 



⑥ Client helper unpackages the returned values and returns 
them to the client object. To the client object, this was all 
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RMI: the big picture 


Java RMl the Pig Picture 


Okay ， you’ve got the gist of how remote methods work; 
now you just need to understand how to use RMI to 
enable remote method invocation. 

What RMI does for you is build the client and service 
helper objects, right down to creating a client helper 
object with the same methods as the remote service. The 
nice thing about RMI is that you don’t have to write 
any of the networking or I/O code yourself. With your 
client, you call remote methods (i.e.，the ones the Real 
Service has) just like normal method calls on objects 
running in the client’s own local JVM. 

RMI also provides all the runtime infrastructure to make 
it all work, including a lookup service that the client can 
use to find and access the remote objects. 


There is one difference between RMI calls and local 
(normal) method calls. Remember that even though to 
the client it looks like the method call is local, the client 
helper sends the method call across the network. So 
there is networking and I/O. And what do we know 
about networking and I/O methods? 

They’re risky! They can fail! And so, they throw 
exceptions all over the place. As a result, the client does 
have to acknowledge the risk. We’ll see how in a few 
pages. 


RMI Nomenclature: in RMI, the client helper is a ( stub 9 and the 
service helper is a ^skeleton 9 . 



skclcio 




Now let’s go through all the steps needed to make an object into a 
service that can accept remote calls and also the steps needed to 
allow a client to make remote calls. 


咖 eiU 3 0h 

sc\rvc\r side 
is Udliha 
s ^lcioh behavior 


You might want to make sure your seat belt is fastened; there are 
a lot of steps and a few bumps and curves - but nothing to be too 
worried about. 
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Making the Remote service 

This is an overview of the five steps for making the remote service. In other words, the A n 5MI Detour 

steps needed to take an ordinary object and supercharge it so it can be called by a remote 
client. We’ll be doing this later to our GumballMachine. For now, let’s get the steps down 
and then we’ll explain each one in detail. 


Step one: 

Make a Remote Interface 

The remote interface defines the methods that 
a client can call remotely. It’s what the client 
will use as the class type for your service. Both 
the Stub and actual service will implement 
this! 


public inteil 
MyRemote 
Remote (} 




MyService.java 


fate ^ 

卜 ， tlu 一 俨 
^ ^ ta \\. 


Step two: 

Make a Remote Implementation 

This is the class that does the Real Work. It 
has the real implementation of the remote 
methods defined in the remote interface. 


public MyR 

UnicasIRfiiTOteObjecl 
imfilemenls 
MyRemote{} 


^ Real Se 一 e; 十屮 ” 


with W methods do 

«al wo,k. 

MyServicelmpl.java yemoie ate 


It’s the object that the client wants to call 
methods on (e.g.，our GumballMachine!). 

Step three: 

Generate the stubs and skeletons using rmic 

These are the client and server ‘helpers’. You 
don’t have to create these classes or ever look 
at the source code that generates them. It’s all 
handled automatically when you run the rmic 
tool that ships with your Java development kit. 

Step four: 

Start the RMI registry (rmiregistry) 

The rmiregistry is like the white pages of a phone 
book. It’s where the client goes to get the proxy 
(the client stub/helper object). 

Step five: 

Start the remote service 


,.f • s pi'ts ou-t -ty/o 

“ ^ sscs ^ ^ 

• 呵 Uc 山七咖 dass - Wp 作 obie^t. 


hew 


File Edit Window Help Eat 


% rmic MyServicelmpl 



MyServicelmpLStub.class 



MyServicelmpl_Skel.class 


File Edit Window Help Drink 


% rmiregistry 


a _十 


You have to get the service object up and running. Your 
service implementation class instantiates an instance 
of the service and registers it with the RMI registry. 
Registering it makes the service available for clients. 
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make a remote interface 


Step one: make a Remote interface 


① Extend java.rmi.Remote 

Remote is a ‘marker’ interface, which means it has no methods. It has special 
meaning for RMI, though, so you must follow this rule. Notice that we say 
‘extends’ here. One interface is allowed to extend another interface. 



public interface MyRemote extends Remote { 


㈣ 二 


② Declare that all methods throw a RemoteException 

The remote interface is the one the client uses as the type for the service. In 
other words, the client invokes methods on something that implements the 
remote interface. That something is the stub, of course, and since the stub is 
doing networking and 1/O, all kinds of Bad Things can happen. The client 
has to acknowledge the risks by handling or declaring the remote exceptions. If 
the methods in an interface declare exceptions, any code calling methods on a 
reference of that type (the interface type) must handle or declare the exceptions. 


import java.rmi. 




public interface MyRemote extends Remote { 




public String sayHello() throws RemoteException; 


} 


(3) Be sure arguments and return values are primitives or Serializable 

Arguments and return values of a remote method must be either primitive 
or Serializable. Think about it. Any argument to a remote method has to 
be packaged up and shipped across the network, and that’s done through 
Serialization. Same thing with return values. If you use primitives, Strings, and 
the majority of types in the API (including arrays and collections), you’ll be fine. 
If you are passing around your own types, just be sure that you make your classes 
implement Serializable. 

public String sayHello() throws RemoteException; 

^ 代 Wh values 3e 七 paikaged up a ^d 


ve,r y ^oie method isll i s 
Visk/. Dedlan^g 

oh cvcv*y 

•method -po^cs the diCh 七 
七 o pay attchtioh 3hd 
a^khowlcdjc that thirds 
叫 hi ho-t wovk. 
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Step two: make a Remote implementation 

① Implement the Remote interface 

Your service has to implement the remote interface —— the one with 
the methods your client is going to call. 

public class MyRemoteImp1 extends UnicastRemoteObject implements MyRemote { 

public String sayHello() { ^ - ^ 

return ''Server says, 、 Hey f "; 

} 

// more code in class 

} 

(5) Extend UnicastRemoteObject 

In order to work as a remote service object, your object needs some functionality 
related to c being remote’. The simplest way is to extend UnicastRemoteObject 
(from the java.rmi.server package) and let that class (your superclass) do the 
work for you. 

public class MyRemo teImp1 extends UnicastRemoteObject implements MyRemote { 


Th « Will make swve iha-t 

i 呷十 d a |K he 

, the you ir»p| e — 七 . 

I 内七 his case, theve^ 0 hly o^e. 



An BMI Detour 


③ 


Write a no-arg constructor that declares a RemoteException 

Your new superclass, UnicastRemoteObject, has one little problem — its 
constructor throws a RemoteException. The only way to deal with this is to 
declare a constructor for your remote implementation, just so that you have a 
place to declare the RemoteException. Remember, when a class is instantiated, 
its superclass constructor is always called. If your superclass constructor throws 
an exception, you have no choice but to declare that your constructor also throws 
an exception. 

public MyRemotelmpl() 


throws RemoteException { } 


④ Register the service with the RMI registry 


do,'Uavao - 


Now that you’ve got a remote service, you have to make it available to remote 
clients. You do this by instantiating it and putting it into the RMI registry (which 
must be running or this line of code fails). When you register the implementation 
object, the RMI system actually puts the stub in the registry, since that’s what the 
client really needs. Register your service using the static rebindO method of the 
java.rmi.Naming class, 
try { 

My Remote service = new MyRemotelmpl (); 

Naming. rebind (''RemoteHello" , service); 

} catch(Exception ex) {...} 


( 妊 at 
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stubs and skeletons 


Step three: generate stubs and skeletons 

① Run rmic on the remote implementation class 
(not the remote interface) 


The rmic tool, which comes with the Java software 
development kit, takes a service implementation and 
creates two new classes, the stub and the skeleton. It uses 
a naming convention that is the name of your remote 
implementation, with either 一 Stub or —Skel added to 
the end. There are other options with rmic, including 
not generating skeletons, seeing what the source code 
for these classes looked like, and even using HOP as 
the protocol. The way we’re doing it here is the way 
you’ll usually do it. The classes will land in the current 
directory (i.e. whatever you did a cd to). Remember, 
rmic must be able to see your implementation class, so 
you’ll probably run rmic from the directory where your 
remote implementation is located. (We’re deliberately 
not using packages here, to make it simpler. In the Real 
World, you’ll need to account for package directory 
structures and fully-qualified names). 


七 ^ K tlass H 
tlass «aw>e- 


I File Edit Window Help Whuffie | 


% rmic My Remo te Impl 


fiohct ^a*t 70U 
OY\ crr\d. v ^ s 七 







MyRemotelmpLStub.class 



MyRemotelmpLSkel.class 


Step four: run rmiregistry 


① Bring up a terminal and start the rmiregistry. 

Be sure you start it from a directory that has access to 
your classes. The simplest way is to start it from your 
‘classes’ directory. 


I File Edit Window Help Huh? | 


% rmiregistry 


Step five: start the service 


① Bring up another terminal and start your service 

This might be from a main() method in your remote 
implementation class, or from a separate launcher class. 

In this simple example, we put the starter code in the 
implementation class, in a main method that instantiates the 
object and registers it with RMI registry. 


File Edit Window Help Huh? | 


java MyRemotelmpl 
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Complete code for the server side 


the proxy pattern 


The Remote interface: 


import java.rmi.*; m ^ C v^aC-C 3VC ^ javav-wi f 3 , 

■ ，士 山 te MUST ^Udjava.^.R^ote 

public interface MyRemote extends Remote { 

public String sayHello () throws RemoteException; youir methods rwus 七 

} dcdlavc a Rc^otcExdcp-tioh. 


The Remote service (the implementation): 


import java.rmi.*; ^_ 

import java.rmi.server.*; 


狄， of 、“ L K 


public class MyRemoteImpl extends UnicastRemoteObject implements MyRemote { 


public String sayHello () { V^ ou have to implcmcht dll the ^ ou ^IU£T ir^p| Cry>Ch l 

return ''Server says, 'Hey ，"； methods, o-f Course But ^ 

} y^ohu tha-t you do HOT have io 

AttUrt the RcmotcExdcptioh. 

public MyRemotelmplO throws RemoteException { } y ouy . supc rdlass to^sbryACior (^ov 

^^ LitaslRer^o-teObjedD detla^s ar, Wcji 伽 
public static void main (String[] args) { — 祕七 ' 七二 二 —（i 


try { 

MyRemote service = new MyRemotelmpl(); 
Naming, rebind (''RemoteHello" , service); 
} catch(Exception ex) { 
ex.printstackTrace (〉； 


lAniuoj V/* j ——- .j 

x/OU «M*st Yiv.-te a toKs-tv-ut-U-, betawe I 七 ^eaw 
that 70UV dowivuttov is dall'm9 viskv code t.ts 
sw^ev dons-tvwt-tov)- 

Mme you yLisiJ J. 卜， lebindO. The 
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how to get the stub object 


How does the client get the 
stub object? 


The client has to get the stub object (our proxy), since 
that’s the thing the client will call methods on. And that’s 
where the RMI registry comes in. The client does a 
‘lookup’，like going to the white pages of a phone book, 
and essentially says ， “Here’s a name, and I’d like the stub 
that goes with that name.” 


Let’s take a look at the code we need to lookup and 
retrieve a stub object. 


C^de J]p Cl^se 
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MyRemote service 
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(MyRemote) Naming. lookup (''rmi : //127.0.0.1/RemoteHello"); 
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How it works... 

① Client does a lookup on the RMI registry 

Naming. lookup (、'rmi : //127.0.0.1/RemoteHello ”）； 

② RMI registry returns the stub object 

(as the return value of the lookup method) and RMI deserializes the stub 
automatically. You MUST have the stub class (that rmic generated for you) 
on the client or the stub won’t be deserialized. 

③ Client invokes a method on the stub, as if the 
stub IS the real service 
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the remote client 


Complete client code 


import java.rmi.*; 


The dass 




public class MyRemoteClient { 

public static void main (String[] args) { 
new MyRemoteClient().go(); 

} 


public void go() { 




try { 

MyRemote service 


String s = service.sayHello(); 


sC 鮮心。 

(MyRemote) Naming. lookup (''rmi: //127.0.0.1/RemoteHello"); 

^ 7 ' 

^ ^ ou -the IP 

System, out .pr in tin (s) duress o\r hos-thar^c. 

} catch (Exception ex) { H looks \usi liU .. 
ex.printStackTraceO ; r» e £hod Call./ 


a^di ^ 


a^ki 


I . . I w ^ u 


U GeeJ: - 

How does the client get the stub class? 

Now we get to the interesting question. Somehow, some way, the client must have the stub class 
(that you generated earlier using rmic) at the time the client does the lookup, or else the stub won’t 
be deserialized on the client and the whole thing blows up. The client also needs classes for any 
serialized objects returned by method calls to the remote object. In a simple system,you can simply 
hand-deliver the these classes to the client. 

There’s a much cooler way, although it’s beyond the scope of this book. But just in case you’re 
interested, the cooler way is called "dynamic class downloading’: With dynamic class downloading, 
Serialized objects (like the stub) are"stamped”with a URL that tells the RMI system on the client where 
to find the class file for that object. Then, in the process of deserializing an object, if RMI can’t find the 
class locally, it uses that URL to do an HTTP Get to retrieve the class file. So you'd need a simple web 
server to serve up class files, and you’d also need to change some security parameters on the client. 
There are a few other tricky issues with dynamic class downloading, but that’s the overview. 

For the stub object specifically, there’s another way the client can get the class. This is only available in 
Java 5, though. We’ll briefly talk about this near the end of the chapter. 
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The top three things programmers do wrong with RMI are: 

1) Forget to start rmiregistry before starting remote service (when the service is registered using 
Naming.rebindO, the rmiregistry must be running!) 

2) Forget to make arguments and return types serializable (you won’t know until runtime; this is 
not something the compiler will detect.) 

3) Forget to give the stub class to the client. 
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MyRemote.class 
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remote gumball monitor 


Pack to our frumballMachine 
remote proxy 

Okay, now that you have the RMI basics down, you’ve 
got the tools you need to implement the gumball 
machine remote proxy. Let’s take a look at how the 
GumballMachine fits into this framework: 



戊 0)S desktop 
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wth a Ji/zVj. 


TWis is . 

Mon'iW tode -^ 
«*ses a to 
talk to vemote 
ftumball matWcs. 


Server heap 



The skele-toh atteyis -the 
^oie dalls ahd 
eve^yihihg wovk oh -the 
side. 


二 


OVA- 




OSC 


i to 


vaSC- 


450 


Chapter 11 




the proxy pattern 


fretting the frumballMachine ready 
to be a remote service 


The first step in converting our code to use the remote proxy is to enable the 
GumballMachine to service remote requests from clients. In other words, 
we’re going to make it into a service. To do that, we need to: 

1) Create a remote interface for the GumballMachine. This will provide a set 
of methods that can be called remotely. 

2) Make sure all the return types in the interface are serializable. 

3) Implement the interface in a concrete class. 

We’ll start with the remote interface: 


I 


TKis is vcmo-tc 


import java.rmi 


public interface GumballMachineRemote extends Remote { 
public int getCount() throws RemoteException; 
public String getLocation() throws RemoteException; 
public State getState() throws RemoteException; 





All ad 

七 o be pvimi-t'wc ov 
Scvializ^blc • 


\ 

ttcvc avc mc-bKods >/cvc io support. 

tadK OY\t *tKvOY/S 


We have one return type that isn’t Serializable: the State class. Let’s fix it up... 


import java.io.*; 


-- Sevial.z^ble is m iV>e java '.o ?atka^. 


public interface State extends Serializable 
public void insertQuarter(); 
public void ejectQuarter(); 
public void turnCrank(); 
public void dispense(); 


I 


TV>er> we jw-t extend tV>e Sevial.z^ble 
mtev-fade (wWidh V>as no meihods m iv- 
^ State m all iV>e subclasses tar. 
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Actually, we’re not done with Serializable yet; we have one problem with State. As you may 
remember, each State object maintains a reference to a gumball machine so that it can call the 


gumball machine’s methods and change its state. We don’t want the entire gumball machine 
serialized and transferred with the State object. There is an easy way to fix this: 

public class NoQuarterState implements State { 
transient GumballMachine gumballMachine; 


// all other methods here 


add tV>e -tvar.sietr.-t key^ovd to tV>e 
S_ba_atWme \^iaue variable- TW 
yis -the J\/M r>ot io seviali« -tWs held. 
Kote -tKa-t iW.s dan be da 呼二咖 

i-f you -tvy -to -bWis -f ield out its 

beer. sevial'.Md ar>d iva^ewed- 


We’ve already implemented our GumballMachine, but we need to make sure it can act as a service and 
handle requests coming from over the network. To do that, we have to make sure the GumballMachine is 
doing everything it needs to implement the GumballMachineRemote interface. 

As you’ve already seen in the RMI detour, this is quite simple, all we need to do is add a couple of things... 


Fivs-t, Y/c Y\ttd io import 
v-mi padkays. / 


import java.rmi•*; 
import j ava.rmi.server.*; 


gumball Mat Wmc 
30 . 1 % "to subdldss "t-Kc 
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私七 as a 咖 。 tc ^v,de. ir»— e «Uhe remote i 


public class GumballMachine 

extends UnicastRemoteObject implements GumballMachineRemote 

{ 

// instance variables here 


public GumballMachine(String location, int numberGumballs) throws RemoteException { 
// code here 


public int getCount() { 
return count; 


public State getState() { 
return state; 


public String getLocation() { 

return location; 




That’S 1 七 ’ /Vo 七 h mg 

/ hcv-c at all/ 



… ahd ihe dohstirudtov heeds 
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// other methods here 
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Registering with the RM1 registry... 


That completes the gumball machine service. Now we just need to fire it up so it can 
receive requests. First, we need to make sure we register it with the RMI registry so 
that clients can locate it. 

We’re going to add a little code to the test drive that will take care of this for us: 


public class GumballMachineTestDrive { 


public static void main(String[] args) { 

GumballMachineRemote gumballMachine = null; 
int count; 

if (args.length < 2) { 

System.out .println (''GumballMachine <name> <inventory>"); 
System.exit(1); 

} 


try 


count = Integer.parselnt(args[1]); 


Fiirst ” 时 ed io a tvy/datdh blodk 
a<ro?d the gumball msUtiat 咖 betause 
^Ohstvudtor cay\ how throw cxdcftiohs. 


ouv* 


gumballMachine = 

new GumballMachine(args[0], count); 

Naming • rebind ('、//’’ + args [0] + ''/gumba lima chine", gumballMachine); 

} catch (Exception e) { ^ 

e. printStackTrace () ; 

} Wc also add ta\\ io 

publishes stub 

^ u^dev* 七 he 

Let’s go ahead and get this running ... 厂 丁心 vVc v-c US ^ ^atWmes, 'you 

, rc^is-try scrV.dc up T，.. i 0 ^ ow 

Run "this ■first I viWmoi. J 


} 


File Edit Window Help Huh? 


rmiregistry 


File Edit Window Help Huh? 






java GumballMachineTestDrive seattle.mightygumball.com 100 


Ru” this stCov\d> 


This ^cts i\\t ^umballMatWrnc up ar\d v-uwmj 
artd vc^is-tevs i*t RMl v-C^is-tvy- 
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Now for the &umballMohitor client... 


Remember the GumballMonitor? We wanted to reuse it without 
having to rewrite it to work over a network. Well, we’re pretty much 
going to do that, but we do need to make a few changes. 


import java.rmi.' 


public class GumballMonitor { 

GumballMachineRemote machine; 


女 ’ ,• veW o" ' rem ° ie 

^ w ballMatWme t'ass. 



public GumballMonitor(GumballMachineRemote machine) { 
this.machine = machine; 

} 


public void report() { 
try { 

System.out .println (''Gumball Machine : '' + machine.getLocation ()); 

System.out .println (''Current inventory: '' + machine .getCount () + '' gumballs"); 
System, out .println (''Current state : 、' + machine. getState ()); 

} catch (RemoteException e) { 
e.printStackTrace(); 

} 

} 


I! e , also ^ io e ^ ep tio,s 

as we iry h> invoke r» e ihods 
that a«re ult^ately ha PP e 叫術七 he M ^ wov . k . 
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Writing the Monitor test drive 

Now we’ve got all the pieces we need. We just need to write some 
code so the CEO can monitor a bunch of gumball machines: 


Heve’s the test A^c- The 

CtO *»S -to y\AY\ 七 Wis! 


import java.rmi. ■ 


public class GumballMonitorTestDrive { 


r 


» c .\\ Uc lo6aW s , 

c L. Wc Crtait ar. 






public static void main(String[] args) { 

String[] location = { 、、 rmi://santafe.mightygumball•com/gumballmachine ”， 

、、rmi : //boulder.mightygumball. com/gumballmachine ’’， 
、、rmi : //seattle .mightygumball. com/gumballmachine"}; 


avvav o-f 
oY\t -fov 
wadWmc- 


GumballMonitor[] monitor = new GumballMonitor[location.length]; 


for (int i=0;i < location.length; i++) { 
try { 

Gumb a UMa chine Remote machine = 



also trtait 


(GumbalIMachineRemote) Naming.lookup(location[i]); 
monitor[i] = new GumballMonitor(machine); 

System.out.println(monitor[i]); 

} catch (Exception e) { 
e.printStackTrace(); 

} 



Nov/ y/c r>ccd "to gc*t d p\ro>cy 
"to v*crwo*tc rwath'mc- 


for(int i=0; i < monitor.length; i++) { 

monitor[i].report(); 



tat\\ 

a^d ou-t »*b 
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TJp Cl^ 
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GumballMachineRemote machine = / \y 

(GumballMachineRemote) Naming.lookup(location[i]); 

monitor[i] = new GumballMonitor(machine); 

} catch (Exception e) { 卜 

e.printStackTrace(); / 

} ( , 

„atWme, treaie H 
a „d ? ass ,U^ 


Awother demo for the CEO of Mighty Gumball... 

Okay, it’s time to put all this work together and give another demo. First let’s make 
sure a few gumball machines are running the new code: 


0^ tacM ma^rnc, VUh v-mivc^is-tvy *m 
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File Edit Window Help Huh? 


% rmiregistry & ^ 

% java GumballMachine santafe.mightygumball.com 100 


File Edit Window Help Huh? 


% rmiregistry & 

% java GumballMachine boulder.mightygumball.com 100 


File Edit Window Help Huh? 
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And mow let^ put the monitor iw the hands of the CEO. 
Hopefully this time he'll love it: 


File Edit Window Help GumballsAndBeyond 


% java GumbalIMonitor 

Gumball Machine : santafe.mightygumball.com 
Current inventory : 99 gumballs 
Current state: waiting for quarter 

Gumball Machine : boulder.mightygumball•com 

Current inventory : 44 gumballs 

Current state: waiting for turn of crank 


The rwemi 七 。 \r i*tc\ra*tcs 
ovcv- verwo 七 e 

mddhihC dhd 乙 dlls rts 

getCouh 七 0 ar\d 
gc-tStatcO me 七 hods. 


Gumball Machine : Seattle.mightygumball•com 
Current inventory : 187 gumballs 
Current state: waiting for quarter 



This is amazing; 
to revolutionize my 
business and blow away the 



声、 


By invoking metkocis on tke proxy, a remote call 
is made across tke wire and a String, an integer 
and a State object are returnect. Because we are 
using a proxy, tke GumLallMonitor ctoesn’t know, 
or care, tkat calls are remote (otker tkan kavingf 
to vony al>out remote exceptions). 
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proxy behind the scenes 



❹ The CEO runs the monitor, which first grabs the proxies to the remote 
gumball machines and then calls getState() on each one (along with 
getCountQ and getLocation()). 


C^O's dcsK。? 
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❺ getState() is called on the proxy, which forwards the call to the remote 
service. The skeleton receives the request and then forwards it to the 
gumball machine. 



❺ SumballMachine returns the state to the skeleton, which serializes it and 
transfers it back over the wire to the proxy. The proxy deserializes it and 
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The Proxy Pattern defined 

We’ve already put a lot of pages behind us in this chapter; as you 
can see, explaining the Remote Proxy is quite involved. Despite 
that, you’ll see that the definition and class diagram for the Proxy 
Pattern is actually fairly straightforward. Note that Remote Proxy is 
one implementation of the general Proxy Pattern; there are actually 
quite a few variations of the pattern, and we’ll talk about them later. 
For now, let’s get the details of the general pattern down. 

Here’s the Proxy Pattern definition: 


The Proxy Pattern provides a surrogate or 
placeholder for another object to control access to it. 


Well, we’ve seen how the Proxy Pattern provides a surrogate or 
placeholder for another object. We’ve also described the proxy as 
a “representative” for another object. 

But what about a proxy controlling access? That sounds a little 
strange. No worries. In the case of the gumball machine, just 
think of the proxy controlling access to the remote object. The 
proxy needed to control access because our client, the monitor, 
didn’t know how to talk to a remote object. So in some sense the 
remote proxy controlled access so that it could handle the network 
details for us. As we just discussed, there are many variations of 
the Proxy Pattern, and the variations typically revolve around the 
way the proxy “controls access.” We’re going to talk more about 
this later, but for now here are a few ways proxies control access: 

■ As we know, a remote proxy controls access to a 
remote object. 

■ A virtual proxy controls access to a resource that is 
expensive to create. 

■ A protection proxy controls access to a resource 
based on access rights. 

Now that you’ve got the gist of the general pattern, check out the 
class diagram... 


Use tke Proxy 
Pattern to create a 
representative object 
tkat controls access 
to anotker otject, 
wkicli may te remote, 
expensive to create or 
in neect oi securing. 
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Let’s step through the diagram... 

First we have a Subject, which provides an interface for the RealSubject and the Proxy. 
By implementing the same interface, the Proxy can be substituted for the RealSubject 
anywhere it occurs. 

The RealSubject is the object that does the real work. It’s the object that the Proxy 
represents and controls access to. 

The Proxy holds a reference to the RealSubject. In some cases, the Proxy may be 
responsible for creating and destroying the RealSubject. Clients interact with the 
RealSubject through the Proxy. Because the Proxy and RealSubject implement the 
same interface (Subject), the Proxy can be substituted anywhere the subject can be 
used. The Proxy also controls access to the RealSubject; this control may be needed 
if the Subject is running on a remote machine, if the Subject is expensive to create in 
some way or if access to the subject needs to be protected in some way. 

Now that you understand the general pattern, let’s look at some other ways of using 
proxy beyond the Remote Proxy... 
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fret ready for Virtual Proxy 

Okay，so far you’ve seen the definition of the Proxy Pattern and you’ve taken a look 
at one specific example: the Remote Proxy. Now we’re going to take a look at a different 
type of proxy, the Virtual Proxy. As you’ll discover, the Proxy Pattern can manifest 
itself in many forms, yet all the forms follow roughly the general proxy design. Why 
so many forms? Because the proxy pattern can be applied to a lot of different use 
cases. Let’s check out the Virtual Proxy and compare it to Remote Proxy: 


Remote Proxy 

With Remote Proxy, the proxy 
acts as a local representative 
for an object that lives in a 
different JVM. A method call 
on the proxy results in the call 
being transferred over the wire, 
invoked remotely, and the result 
being returned back to the proxy 
and then to the Client. 



pv-etty v/cll by r\ow... 
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Virtual Proxy 

Virtual Proxy acts as a 
representative for an object that 
may be expensive to create. The 
Virtual Proxy often defers the 
creation of the object until it 
is needed; the Virtual Proxy 
also acts as a surrogate for 
the object before and while it 
is being created. After that, the 
proxy delegates requests directly to 
the RealSubject. 
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displaying Cl? covers 

Let’s say you want to write an application that displays your favorite compact disc 
covers. You might create a menu of the CD titles and then retrieve the images 
from an online service like Amazon.com. If you’re using Swing, you might create 
an Icon and ask it to load the image from the network. The only problem is, 
depending on the network load and the bandwidth of your connection, retrieving 
a CD cover might take a little time, so your application should display something 
while you are waiting for the image to load. We also don’t want to hang up the 
entire application while it’s waiting on the image. Once the image is loaded, the 
message should go away and you should see the image. 


An easy way to achieve this is through a virtual proxy. The virtual proxy can 
stand in place of the icon, manage the background loading, and before the 
image is fully retrieved from the network, display “Loading CD cover, please 
wait."”. Once the image is loaded, the proxy delegates the display to the Icon. 
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designing the Cl? cover Virtual Proxy 

Before writing the code for the CD Cover Viewer, let’s look at the class diagram. 
You’ll see this looks just like our Remote Proxy class diagram, but here the proxy is 
used to hide an object that is expensive to create (because we need to retrieve the data 
for the Icon over the network) as opposed to an object that actually lives somewhere 
else on the network. 
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Icon 
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七 he irwage is loaded ； delegates to 
to display the i^a^c- 


O ImageProxy first creates an Imagelcon and starts 
loading it from a network URL. 

❾ While the bytes of the image are being retrieved, 
ImageProxy displays “Loading CD cover, please 
wait...”. 

O When the image is fully loaded, ImageProxy del¬ 
egates all method calls to the image icon, including 
paintlcon(), getWidth() and getHeight(). 

❹ If the user requests a new image, we’ll create a 
new proxy and start the process over. 


464 


Chapter 11 





the proxy pattern 


Writing the Image Proxy 


class ImageProxy implements 
Imagelcon imageIcon; 

URL imageURL; 

Thread retrievalThread; 
boolean retrieving = fa 



public ImageProxy(URL url) { imageURL = url; } 


«interface» 

Icon 

getlconWidthf) 

getlconHeight() 

paintlconf) 
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public int getlconWidth() { 

if (imagelcon != null) { 

return imagelcon•getlconWidth(); 
} else { 

return 800 ; 



1/Vc pass i\\t URL -b^c imay \r\io 
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public int getlconHeight() { 
if (imagelcon != null) { 

return imagelcon•getlconHeight(); 
} else { 

return 600 ; 
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} 


public void paintlcon (final Component c, Graphics g, int x, int y) { 
if (imagelcon != null) { 

imagelcon.paintlcon(c, g, x, y); 

} else { 

g.drawstring(''Loading CD cover, please wait...", x+300, y+190); 
if (!retrieving) { 

retrieving = true; 

retrievalThread = new Thread(new Runnable() { 

public void run() { 
try { 

imagelcon = new Imagelcon (imageURL, ''CD Cover"); 
c.repaint (); 

} catch (Exception e) { 
e.printStackTrace(); 


})； 

retrievalThread.start(); 


Hcv-c^s y/Iicvc 七 … "tc 圹 cs 七 iy^. 

This Code pa'm-ts i\\t \Coy\ oy\ 

T"^ stvee^ (by to {ht 

ima^eko^X ttowcvcv, i-f v/c dor!i ^avc 
a ^ully dv-catcd Ima^cko^ wc 

oy\C Let’s look dosev* 
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image proxy up close 


C^elJp 0 ] 雜 


This method is tailed it's -time -to pamt -t^c \CoY\ Q}r\ i\\t sdvcCh. 


public void paintlcon (final Component c, Graphics g, int x, int y) { 
if (imageIcon != null) { 


imagelcon.paintlcon(c, g, x, y); 
else { 


l-f we’ve 30 七扣 item already, v/e 30 

ahead a^d -tell i*t io pa'm-t itself. 


g.drawstring(''Loading CD cover, please wait...' 
if (!retrieving) { 


retrieving = true; 

retrievalThread = new Thread(new Runnable() { 
public void run() { 

try { 

imagelcon = new Imagelcon(imageURL r 
c.repaint(); 

} catch (Exception e) { 
e.printStackTrace(); 


x+300, y+190); 

^"thcv-wisc wc 
dis play ihc 


''loadihi 


'CD Cover"); 


} 



3 message- 


})； 


retrievalThread. start (); 


，: X :。 ⑼ S 士:？ f 
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VayUp Cl^se 




Y/C 


ave^-t alveady ^ «V.eve tV»e W 等 .. 

f ...-ther, it's We -to s-tart : 如 , •; 七心 = 二 

厶 should be okay heve m tev">s t^ead sa+etv 


if 


(!retrieving) 
retrieving = 


true; 




retrievalThread = new Thread(new Runnable() { 

public void run() { 
try { 

imageIcon = new ImageIcon(imageURL, 
c.repaint(); 

} catch (Exception e) 

e.printstackTrace(); 


VVc do^i Y/a 於七七 o u ? 

c^tivc uscv m-tcv^adc, so wcv-c 
50^5 io use a^otKcv tWead 七。 
VC*tv-*»CVC "tV^C iw 35 c - 



'CD Cover"); 




out 


}); 

retrievalThread.start() 


tVhch v/c have -the imaje, 

"tdl 七 ha 七 we 

i^ccd io be ircpa'mtcd. 


匕 y—t lh 

二:， w “。士 
^ ^in ihe 

'^9 e « load ed . 


So, the hc>ct tir^c the display is pamted a-ftev the Uagckon is ihs-bntiatca, the pa'mtkoi 
r^ctliod will paiivt the ir^age, no 七七 he load'm^ message- 
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design puzzle 


Design Puzzle 


The ImageProxy class appears to have two states that are controlled 
by conditional statements. Can you think of another pattern that 
might clean up this code? How would you redesign ImageProxy? 


class ImageProxy implements Icon { 

// instance variables & constructor here 

public int getlconWidth() { 

if (imagelcon != null) { 

return imagelcon.getlconWidth(); 

} else { 

return 800; 

} 

} 

public int getlconHeight() { 

if (imagelcon != null) { 

return imagelcon.getlconHeight (); 
} else { 

return 600; 

} 

} 




Two s-ta-fccs 




Two s-ta-tcs 


public void paintlcon (final Component c, Graphics 
if (imagelcon != null) { 

imagelcon.paintlcon(c, g, x, y); 

} else { 

g. drawstring (''Loading CD cover, please we 
// more code here 


g, int x, int y) { 


Two s-ta-tcs 


x+300, y+190); 
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Testing the CP Cover Viewer 

Okay, it’s time to test out this fancy new virtual proxy. Behind the 
scenes we’ve been baking up a new ImageProxyTestDrive that sets up 
the window, creates a frame, installs the menus and creates our proxy. 
We don’t go through all that code in gory detail here, but you can 
always grab the source code and have a look, or check it out at the end 
of the chapter where we list all the source code for the Virtual Proxy. 

Here’s a partial view of the test drive code: 



public class ImageProxyTestDrive { 

ImageComponent imageComponent; 

public static void main (String[] args) throws Exception { 

ImageProxyTestDrive testDrive = new ImageProxyTestDrive(); 


public ImageProxyTestDrive() throws Exception{ 
// set up frame and menus ^ 

Icon icon = new ImageProxy(initialURL); 


hire y/c ^vcaic ah image pvoxy 釙 d set 

i"t "to •mi'tidl URL. you 

dKoosc 3 sclcdtiorv -fvorw -fcKc CD mchu, 
you || yt a new pvoxy. 


imageComponent = new 工 mageComponent(icon); 
frame.getContentPane().add(imageComponent); 




Finally y/c add "tKc |>v-ox.y -to -tKc -fv-amc 
so ii be displayed- 


Mcy-i v/c v/vap ouv ^vox.y m a 

so it C3y\ be sdded {jo 
■tKc -fvamc. TKc dompo 灼 e»vt will 
■take ^av-c o-f -tKc fvox-y^s y/id^tK, 
KcijK-t dhd similav- details. 


Now let’s run the test drive: 



Q Use the menu to load different CD covers; watch the 
proxy display “loading” until the image has arrived. 

❺ Resize the window as the “loading” message is 

displayed. Notice that the proxy is handling the loading 
without hanging up the Swing window. 



O Add your own favorite CDs to the ImageProxyTestDrive. 
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behind the scenes with image proxy 


What did we do? 

❶ We created an ImageProxy for the display. The paintIcon() 
method is called and ImageProxy fires off a thread to 
retrieve the image and create the Imagelcon. 


論 nd 屬 

ihe Scenes^ 5 ^ 
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The Remote Proxy and Virtual 
Proxy seem so different to me; are 
they really ONE pattern? 

You’ll find a lot of variants of the 
Proxy Pattern in the real world; what 
they all have in common is that they 
intercept a method invocation that 
the client is making on the subject. 

This level of indirection allows us to 
do many things, including dispatching 
requests to a remote subject, providing 
a representative for an expensive 
object as it is created, or, as you’ll see, 
providing some level of protection that 
can determine which clients should be 
calling which methods. That’s just the 
beginning; the general Proxy Pattern 
can be applied in many different ways, 
and we’ll cover some of the other ways 
at the end of the chapter. 

ImageProxy seems just like 
a Decorator to me. I mean, we are 
basically wrapping one object with 
another and then delegating the 
calls to the Imagelcon. What am I 
missing? 

Sometimes Proxy and Decorator 
look very similar, but their purposes are 
different: a decorator adds behavior to 
a class, while a proxy controls access 
to it. You might say,"Isn’t the loading 
message adding behavior?” In some 


Dumffc^iiestiPiis 

ways it is; however, more importantly, 
the ImageProxy is controlling access 
to an Imagelcon. How does it control 
access? Well, think about it this way: 
the proxy is decoupling the client from 
the Imagelcon. If they were coupled 
the client would have to wait until each 
image is retrieved before it could paint 
it entire interface. The proxy controls 
access to the Imagelcon so that before 
it is fully created, the proxy provides 
another on screen representation. 

Once the Imagelcon is created the 
proxy allows access. 


You are talking about a special¬ 
ized form of a Virtual Proxy called 
a Caching Proxy. A caching proxy 
maintains a cache of previous created 
objects and when a request is made it 
returns cached object, if possible. 

We’re going to look this and at several 
other variants of the Proxy Pattern at 
the end of the chapter. 

I see how Decorator and Proxy 
relate, but what about Adapter? An 
adapter seems very similar as well. 


How do I make clients use the 
Proxy rather than the Real Subject? 

Good question. One common 
technique is to provide a factory that 
instantiates and returns the subject. 
Because this happens in a factory 
method we can then wrap the subject 
with a proxy before returning it. The 
client never knows or cares that it’s 
using a proxy instead of the real thing. 

I noticed in the ImageProxy 
example, you always create a new 
Imagelcon to get the image, even 
if the image has already been 
retrieved. Could you implement 
something similar to the ImageProxy 
that caches past retrievals? 


Both Proxy and Adapter sit in 
front of other objects and forward 
requests to them. Remember that 
Adapter changes the interface of 
the objects it adapts, while the Proxy 
implements the same interface. 

There is one additional similarity that 
relates to the Protection Proxy. A 
Protection Proxy may allow or disallow 
a client access to particular methods 
in an object based on the role of the 
client. In this way a Protection Proxy 
may only provide a partial interface to 
a client, which is quite similar to some 
Adapters. We are going to take a look 
at Protection Proxy in a few pages. 
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fireside chats: proxy and decorator 


Fireside Ghats 



Tonights talk ： Projcjr and Decorator get intentional. 


Projrjr 

Hello, Decorator. I presume you’re here 
because people sometimes get us confused? 

Me copyingj ⑽ r ideas? Please. I control access 
to objects. You just decorate them. My job is 
so much more important than yours it’s just not 
even funny. 


Fine, so maybe you’re not entirely frivolous... 
but I still don’t get why you think I’m copying 
all your ideas. I’m all about representing my 
subjects, not decorating them. 


I don’t think you get it, Decorator. I stand in for 
my Subjects; I don’t just add behavior. Clients 
use me as a surrogate of a Real Subject, because 
I can protect them from unwanted access，or keep 
their GUIs from hanging up while they’re waiting 
for big objects to load，or hide the fact that their 
Subjects are running on remote machines. I’d say 
that’s a very different intent from yours! 


Decorator 


Well, I think the reason people get us confused 
is that you go around pretending to be an 
entirely different pattern, when in fact, you’re 
just a Decorator in disguise. I really don’t 
think you should be copying all my ideas. 


“Just” decorate? You think decorating is some 
frivolous unimportant pattern? Let me tell 
you buddy，I add behavior. That’s the most 
important thing about objects ■ what they do\ 


You can call it “representation” but if it looks 
like a duck and walks like a duck... I mean，just 
look at your Virtual Proxy; it’s just another 
way of adding behavior to do something while 
some big expensive object is loading, and your 
Remote Proxy is a way of talking to remote 
objects so your clients don’t have to bother 
with that themselves. If s all about behavior, 
just like I said. 


Call it what you want. I implement the same 
interface as the objects I wrap; so do you. 
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Proxy 

Okay, let’s review that statement. You wrap 
an object. While sometimes we informally say 
a proxy wraps its Subject, that’s not really an 
accurate term. 

Think about a remote proxy... what object am 
I wrapping? The object I’m representing and 
controlling access to lives on another machine! 
Let’s see you do that. 


Sure ， okay, take a virtual proxy... think about 
the CD viewer example. When the client first 
uses me as a proxy the subject doesn’t even 
exist! So what am I wrapping there? 

I never knew decorators were so dumb! Of 
course I sometimes create objects, how do you 
think a virtual proxy gets its subject! Okay, you 
just pointed out a big difference between us: 
we both know decorators only add window 
dressing; they never get to instantiate anything. 


Hey, after this conversation I’m convinced 
you’re just a dumb proxy! 


Very seldom will you ever see a proxy get into 
wrapping a subject multiple times; in fact, if 
you’re wrapping something 10 times, you 
better go back reexamine your design. 


Decorator 


Oh yeah? Why not? 


Okay, but we all know remote proxies are kinda 
weird. Got a second example? I doubt it. 


Uh huh, and the next thing you’ll be saying is 
that you actually get to create objects. 


Oh yeah? Instantiate this! 


Dumb proxy? I’d like to see you recursively 
wrap an object with 10 decorators and keep 
your head straight at the same time. 


Just like a proxy, acting all real when in fact you 
just stand in for the objects doing the real work. 
You know, I actually feel sorry for you. 
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protection proxy 


Using the Java API's Proxy to create a 
protect iow proxy 

Java’s got its own proxy support right in the java.lang.reflect package. With this package, Java 
lets you create a proxy class on the fly that implements one or more interfaces and forwards 
method invocations to a class that you specify. Because the actual proxy class is created at 
runtime, we refer to this Java technology as a dynamic proxy. 

We’re going to use Java’s dynamic proxy to create our next proxy implementation (a 
protection proxy), but before we do that, let’s quickly look at a class diagram that shows how 
dynamic proxies are put together. Like most things in the real world, it differs slightly from 
the classic definition of the pattern: 



〈〈 interface 》 

Subject 


request() 


〈〈 interface 〉〉 

InvocationHandler 


invoke() 







Proxy 


request() 


△ 


InvocationHandler 


、 TV>c Pv 。 巧一 

〆 of tlasscs. 


,*\s*bs 


invokeQ 


r 

Tk Pv-oxy is gchcvatcd 
by Java implements 
Chtilrc Subject 


Vou su ?? lv |r,vodatior,Har,dlev, M ^ 

Lsed alUetV>od tails that ave mvoked or, the 
pv-o^v- The ktaWttandlev tor«tvols addess to 
the methods oJf -the RealSwbjedt 


Because Java creates the Proxy class for you, you need a way to tell the Proxy class what to do. You can’t 
put that code into the Proxy class like we did before, because you’re not implementing one directly. So, if 
you can’t put this code in the Proxy class, where do you put it? In an InvocationHandler. The job of the 
InvocationHandler is to respond to any method calls on the proxy. Think of the InvocationHandler as the 
object the Proxy asks to do all the real work after it’s received the method calls. 

Okay, let’s step through how to use the dynamic proxy... 
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Matchmaking in Objectville 

Hot 

Every town needs a matchmaking service, right? You’ve risen to the task and 
implemented a dating service for Objectville. You’ve also tried to be innovative by 
including a “Hot or Not” feature in the service where participants can rate each 
other - you figure this keeps your customers engaged and looking through possible 
matches; it also makes things a lot more fun. 

Your service revolves around a Person bean that allows you to set and get information 
about a person: 


以:， 一 


丁 k • 


public interface PersonBean { 

String getName(); 

String getGender(); 

String getlnterests(); 
int getHotOrNotRating(); 




void setName(String name); 
void setGender(String gender); 


void setlnterests(String interests); 


void setHotOrNotRating(int 



1/Vc 6 扣 also set tKc same 
m-fovma-tioh *tK\roujK -fcKc 
vespedtive method dalls. 


rating); 


t) 




Now let’s check out the implementation... 
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personbean needs protecting 


The PersoH^ean implementatioH 


TKc Pcv-sohBcah|m^l -tKc PcvsohBcah 

〆 

public class PersonBeanlmpl implements PersonBean { 
String name; 

String gender; 

String interests; ^ - The ihs-tar»fic vav-iables. 

int rating; 

int ratingCount = 0; 


public String getName() { 

return name; 

} 

public String getGender() 
return gender; 



■tv>c a^^v-o^v-ia-tc 'ms-tar\tc variable … 


public String getlnterests() { 
return interests; 

} 

public int getHotOrNotRating() { 

if (ratingCount == 0) return 0; 
return (rating/ratingCount); 


-fov- 

gc-tttoiOvNotRaimgO, 

(2^ 〆 一 topics avcvajc o-P 

v-atmgs by d'wid'mj -kVic vatmgs 
by vatmjCourv-t. 


public void setName(String name) { 
this.name = name; 

} 

public void setGender(String gender) 
this.gender = gender; 

} 


public void setlnterests(String interests) { 
this.interests = interests; 

} 

public void setHotOrNotRating(int rating) { 
this.rating += rating; 
ratingCount++; 

} 



/W Kcvc S dll -tv^c setbr 

methods, Mt\\ set 

ms*t 3 r\ 6 c v 3 vi 3 blc- 


be 

槪⑽。状 

^"9 io ^ —i， 9 ioU 
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’I wasn’t very successful finding 
dates. Then I noticed someone had changed 
my interests. I also noticed that a lot of people 
are bumping up their HotOrNot scores by giving 
themselves high ratings. You shouldn't be able 
l to change someone else's interests or give 
yourself a rating! , 


While we suspect other factors may be keeping Elroy from getting 
dates, he is right: you shouldn’t be able to vote for yourself or to change 
another customer’s data. The way our PersonBean is defined, any client 
can call any of the methods. 

This is a perfect example of where we might be able to use a Protection 
Proxy. What’s a Protection Proxy? It’s a proxy that controls access to 
an object based on access rights. For instance, if we had an employee 
object, a protection proxy might allow the employee to call certain 
methods on the object, a manager to call additional methods (like 
setSalaryO), and a human resources employee to call any method on the 
object. 



In our dating service we want to make sure that a customer can set his 
own information while preventing others from altering it. We also want 
to allow just the opposite with the HotOrNot ratings: we want the other 
customers to be able to set the rating, but not that particular customer. 
We also have a number of getter methods in the PersonBean, and 
because none of these return private information, any customer should 
be able to call them. 
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five minute drama 



Five minute drama: protecting subjects 

The Internet bubble seems a distant memory; those were the days 
when all you needed to do to find a better, higher-paying job was to 
walk across the street. Even agents for software developers were 
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Pig Picture: creating a dynamic Proxy 
for the PersowPeaw 


We have a couple of problems to fix: customers shouldn’t be changing their own 
HotOrNot rating and customers shouldn’t be able to change other customers’ personal 
information. To fix these problems we’re going to create two proxies: one for accessing 
your own PersonBean object and one for accessing another customer’s PersonBean 

object. That way, the proxies can control what requests can be made in each Remembev tW.s dia^v-am 

circumstance. -fv-om a -fc>/ t>a 乙 k... 


To create these proxies we’re going to use the 
Java API’s dynamic proxy that you saw a few 
pages back. Java will create two proxies for us; 
all we need to do is supply the handlers that 
know what to do when a method is invoked on 
the proxy. 

Step one: 

Create two InvocationHandlers. 

InvocationHandlers implement the behavior 
of the proxy. As you’ll see Java will take care 
of creating the actual proxy class and object, 
we just need to supply a handler that knows 
what to do when a method is called on it. 

Step two: 

Write the code that creates the 
dynamic proxies. 

We need to write a little bit of code to 


«interface» 


«interface» 

Subject 


InvocationHandler 

requestQ 


invokeQ 






RealSubject 


Proxy ； - ► 

InvocationHandler 

request() 

request() 

invoke() 




1 T + 


J o( *tV\csc. 

pvo%Y a*t 


generate the proxy class and instantiate it. 

We’ll step through this code in just a bit. 

Step three: 

Wrap any PersonBean object with 
the appropriate proxy. 

When we need to use a PersonBean object, 
either it’s the object of the customer himself 
(in that case, will call him the “owner”)，or it’s 
another user of the service that the customer is 



VVhen a dws-tomev- is vievf'mj Wis o>wir> bear* 


Wheh a tustomeir is viewing SO r»eohe else s bea« 


checking out (in that case we’ll call him u non- 
owner”). 

In either case, we create the appropriate proxy 
for the PersonBean. 
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create an invocation handler 


Step one: creating Invocation Handlers 


We know we need to write two invocation handlers, one for the owner and one for the non-owner. But 
what are invocation handlers? Here’s the way to think about them: when a method call is made on the 
proxy, the proxy forwards that call to your invocation handler, but not by calling the invocation handler’s 
corresponding method. So, what does it call? Have a look at the InvocationHandler interface: 


〈〈 interface 〉〉 

OwnerlnvocationHandler 


invoke() 


There’s only one method, invoke0, and no matter what methods get called on the proxy, the invokeO 
method is what gets called on the handler. Let’s see how this works: 


① Lefs say the setHotOrNotRatingO 
method is called on the proxy. 




proxy.setHo tOrNo tRating(9) 

Cc __ L 


② The proxy then 
turns around and 
calls invoke。on the 
N InvocationHandler. 


invoke(Object proxy. Method method, Object[] args) 


③ The handler decides 
what it should do 
with the request 
and possibly 
forwards it on to 

the RealSubject. - 

How does the 
handler decide? 

Well find out next. 



mvokc *tV^c wc*tV^od 
oy \ *tV\c Real 
Subjcd-t- 



The Method tlass, ?avt the 
ve-fletW API, tells us >wV>at 
method was tailed or. the ?叫 
via i-b getNa^eO method. 


return method.invoke(person^ args); 


Hcvc mvokc 

tailed 叫 • TW»s 

objed-t >/as passed -to US *m 
mvokc 乙 all. 


mvokc \i 0 Y\ 
RcalSubjcd-t- 


Wi-tK i\\t ov^mal 
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Creating Invocation Handlers coHtinued... 


When invokeO is called by the proxy, how do you know what to do with the call? 
Typically, you’ll examine the method that was called on the proxy and make 
decisions based on the method’s name and possibly its arguments. Let’s implement 
the OwnerlnvocationHandler to see how this works: 


kvotatio^arxllev is o-f the java-la^ledt 
?atkay, so >we need "b insert it. 




All ihvodatioh 

hahdlc^rs ii^plcmcht 
"the / ^vodatiohl+ahdlcv 


import java .lang. reflect.*; ^ 

public class OwnerlnvocationHandler implements InvocationHandler { 


PersonBean person; 

public OwnerlnvocationHandler(PersonBean person) 
this.person = person; 

} 


WYe passed the 
Real Subjei-t i h -the 

匕 onsWtov ad we 

keep a me^eyende to i-fc. 


public Object invoke(Object proxy. Method method. Object[] args) 
throws IllegalAccessException { 


ttcv-c s -the mvokc 
mc-tliod -that gets 
called every -time a 

method is invoked 


oy\ "the p\roX.y. 


try 




if (method.getName () • startsWith (''get")) 
return method.invoke(person, args); 

} else if (method.getName ()• equals (''setHotOrNotRating")) 
throw new IllegalAccessException(); 

} else if (method. getName ()• startsWith ( 、 'set 〃）） { 
return method.invoke(person, args) 


catch ( 工 nvocationTargetException 
e . printStackTrace () ; /V- 


e) 


return null; 


i. 

/-f o-their method is ^H edt 


J^ ,S w 'll hppCh if 
■the … I subject 
"throws cx^cp-ti 


iOh. 





l-P "the rv»c*tiiod is a 
、 geiter, wc go ahead 
3r\d invoke i*t oy\ -the 
{ veal subject 

Othcrv/isc, i-f i*t is "the 
sc*ttt o-iOv N otRatmgO 
method y/c disallow 
i*t by -thiroy/mg a 
|llcgalA^^ss£^cp-tior\. 


Because wc avc 
"the 0 WhC»r 

s d method 
is ^ a^d wc 30 
ahead dhd ihvokc 
i"t oh "the \rc^l 
su bjc^-t. 
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invocation handler 



The NonOwnerlnvocationHandler works just like the 
OwnerlnvocationHandler except that it allows calls to setHotOrNotRatingO 
and it disallows calls to any other set method. Go ahead and write this 
handler yourself: 
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Step two: creating the Proxy class and 
iHstantiating the Proxy object 

Now, all we have left is to dynamically create the proxy class and instantiate the proxy object. Let’s start by writing a 
method that takes a PersonBean and knows how to create an owner proxy for it. That is, we’re going to create the 
kind of proxy that forwards its method calls to the OwnerlnvocationHandler. Here’s the code: 


This meihod -takes a ?e«oin objett *-eal 丄 ^ 
subjetD a«d veWw a Jro^r it betawe the 
? vo^y V>as the sar«e miev^ate as the subjeti, v/e 
v-eWn a PevsonBean- 


PersonBean getOwnerProxy(PersonBean person) 


return (PersonBean) Proxy.newProxylnstance( 
person.getClass().getClassLoader(), 
person.getClass()•getlnterfaces(), 
new OwnerlnvocationHandler(person)); 


Wc pass real subject *m*bo tohS-tvud-tor 
of "the 'mvo^atioh Ka^dlcv*. l-f you look batk 
-two pages you II see is hov/ 七 lie lia^dlcv- ybs 
3C6css \o the v-cal subject 


TWis toAt ertaits i\\t 

No>/ 七 Wis is some 
dodc, SO let's 

i*b tavc-f^lly* 

To trtait a fv-o%Y use 
i\st siaht ncv/Pvo 巧 
mc-tKod i\st Pvo%7 dass... 

^r~ pass I 七七 V>c dassloadcv 
-f oy ouv subjet 七 … 

• a^d "the sc*b o( nrrtc\r*fatcs {\\t 
heeds -to impIcrwCht-. 



•dr>d dh mvo^atioh ha^dlcv, *m 
dase ouv 0^iy\cr |^votaa^d Icv*. 


Sharpen your pencil 


While it is a little complicated, there isn’t much to creating a dynamic proxy. 
Why don’t you write getNonOwnerProxy(), which returns a proxy for the 
NonOwnerlnvocationHandler: 


Take it further: can you write one method getProxy() that takes a 
handler and a person and returns a proxy that uses that handler? 
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Testing the matchmaking service 

Let’s give the matchmaking service a test run and see how it controls access to the 
setter methods based on the proxy that is used. 


public class MatchMakingTestDrive { 

// instance variables here ^ method "to yt -tKmy 


Wm jus 七 trtaits i\\t itsi 
dv-ive and tails 'rb dvivcO 


public static void main(String[] args) { 

MatchMakingTestDrive test = new MatchMakingTestDrive(); 
test.drive(); 


The do^s-tv^-tov 
ouv- PB o-f people m 
ma-bKmakmj strict- 


public MatchMakingTestDrive () { , . ,. ，•“ 

initializeDatabaseO; wUWak 叫 se.v.de- 

} 〆 一 Lrt’s v-c-tv-icvc a 

public void drive () { kT & ⑽如 DB 

PersonBean joe = getPersonFromDatabase (、'Joe Javabean"); > 

PersonBean owner Proxy = getOwnerProxy (j oe) ; ^ - ...a 灼 dl a 灼 

System, out .println (''Name is '、+ owner Proxy • getName ()) ; ovmev \^ 。巧 . 

ownerProxy. setlnterests (''bowling. Go ’’〉； , 

System, out .println (''Interests set from owner proxy"); Call 3 

try { \ a^d a stiitr 

ownerProxy. setHotOrNotRating (10) ; 1 ^, 1 . 11 

} catch (Exception e) { 

System, out .println (''Can't set rating from owner proxy"); dnany t C … 5 * 

} r , 

System, out .println (''Rating is '、 + ownerProxy. getHotOrNotRating () ) ; sKouldy> "t v/ovkf 


PersonBean nonOwnerProxy = ge tNonOwner Proxy (j oe) ; - Nov/ 七 C a 朽一 

System. out. println (''Name is '' + nonOwnerProxy. getName () ) ; oym^r 

try { <^_ ...dy>d ta\\ d 

nonOwnerProxy • setlnterests (''bowling, Go"); 

} catch (Exception e) { - -follov/cd by 3 

System, out .println (''Can f t set interests from non owner proxy ’’）； setbev •个 

nonOwnerProxy. setHotOrNotRating (3) ; TWis shouldn't Movk. 

System, out .println (''Rating set from non owner proxy"); ^ - ^ 

System, out .println (''Rating is '、+ nonOwnerProxy • getHotOrNotRating ()); 丁 ^ ^ 七巧七。 

sc-t 七 he ra 七叫 


// other methods like getOwnerProxy and getNonOwnerProxy here 


TWis should ^jorkf 
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Ruhning the code... 


| File Edit Window Help Born2BDynamic 

% java MatchMakingTestDrive 

Name is Joe Javabean 

Interests set from owner proxy 

Can't set rating from owner proxy 

Rating is 7 

Ouv fvo%Y 

allows a^d 

-bKc Ho-tO^rNo-t ra{ ： \Y\^ 

Name is Joe Javabean 

Can A t set interests from non owner proxy 

Rating set from non owner proxy 

Ouv NohOy/hcv- pvo^y 
allows gettmg ot\\y, but 
also allows dal Is -to set the 

HotOv/Vot v-a-t'mg. 

Rating The new vatmg is 七 he average of the previous va-t'mg, 7 

% the value set by the hoy>owhcv pvo^y, 1 >. 
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q&a about proxy 


So what exactly is the 
"dynamic" aspect of dynamic 
proxies? Is it that I’m instantiating 
the proxy and setting it to a handler 
at runtime? 


No, the proxy is dynamic 
because its class is created at runtime. 
Think about it: before your code runs 
there is no proxy class; it is created on 
demand from the set of interfaces you 
pass it. 

My InvocationHandler seems 
like a very strange proxy, it doesn’t 
implement any of the methods of 
the class it’s proxying. 

That is because the 
InvocationHandler isn’t a proxy - it is 
a class that the proxy dispatches to 
for handling method calls. The proxy 
itself is created dynamically at runtime 
by the static Proxy.newProxylnstanceO 
method. 


Dumffc^uestiPiis 

Yes. The Proxy class has a static 
method called isProxyClass().Calling 
this method with a class will return 
true if the class is a dynamic proxy 
class. Other than that, the proxy class 
will act like any other class that imple¬ 
ments a particular set of interfaces. 

Are there any restrictions on 
the types of interfaces I can pass into 
newProxylnstanceO? 

Yes, there are a few. First, it is 
worth pointing out that we always 
pass newProxylnstanceO an array of 
interfaces - only interfaces are allowed, 
no classes. The major restrictions are 
that all non-public interfaces need to 
be from the same package. You also 
can’t have interfaces with clashing 
method names (that is, two interfaces 
with a method with the same 
signature). There are a few other minor 
nuances as well, so at some point you 
should take a look at the fine print on 
dynamic proxies in the javadoc. 




Is there any way to tell if a 


class is a Proxy class? 


Why are you using skeletons? 
I thought we got rid of those back in 
Java 1.2. 


You're right; we don't need 
to actually generate skeletons. As 
of Java 1.2, the RMI runtime can 
dispatch the client calls directly to 
the remote service using reflection. 

But we like to show the skeleton, 
because conceptually it helps you to 
understand that there is something 
under the covers that’s making that 
communication between the client 
stub and the remote service happen. 

I heard that in Java 5,1 
don’t even need to generate stubs 
anymore either. Is that true? 

It sure is. In Java 5, RMI and 
Dynamic Proxy got together and now 
stubs are generated dynamically using 
Dynamic Proxy. The remote object’s 
stub is a java.Iang.reflect.Proxy instance 
(with an invocation handler) that is 
automatically generated to handle all 
the details of getting the local method 
calls by the client to the remote object. 
So, now you don’t have to use rmic at 
all; everything you need to get a client 
talking to a remote object is handled 
for you behind the scenes. 
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m 

Match each pattern with its description: 


Pattern Description 


DecoratPr 

Wraps anptlier object 
md provides a different 

interface ip it 


Facade 

Wraps ctUPtJier object 
如 d provides additipnal 
t>elictVipr ?pr it 

?roxy 

Wraps anptlier object tP 
control access tp it 

Adapter 

Wraps a launch of 
objects i9 slnipli?/ ihelx 

Interface 
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the zoo 


The Proxy Zoo 

Welcome to the Objectville Zoo! 

You now know about the remote, virtual and protection proxies, but 
out in the wild you’re going to see lots of mutations of this pattern. 
Over here in the Proxy corner of the zoo we’ve got a nice collection 
of wild proxy patterns that we’ve captured for your study. 

Our job isn’t done; we are sure you’re going to see more variations of 
this pattern in the real world, so give us a hand in cataloging more 
proxies. Let’s take a look at the existing collection: 




O' 

Firewall Proxy 

controls access to a 
set of network 


七 : ofb s 州 m 仏 c Uat 咖 
of dorpova-tc sys-tc^s. 


resources, protecting 
the subject from u bad’’ clients. 



Help -fmd a habitat 


Smart Reference Proxy 

provides additional actions 
whenever a subject is 
referenced, such as counting 
the number of references to 
an object. 



Caching Proxy provides 
temporary storage for 
results of operations 
that are expensive. It 
can also allow multiple clients to share 
the results to reduce computation or 
network latency. 


Habitat scert m v/eb sevvev- pv-o^ics as well 

as publis^mj sys-tems. 
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Synchronization Proxy 

provides safe access to 
a subject from multiple 



threads. 



; £o ^° ,s 』 ess i 0 h 的 

sei ^ “ 

d'St^ribuicd Chvi^ohmCht 


ttdp -f'md b habitat 


n Copy-On-Write Proxy 

controls the copying of 
an object by deferring 
the copying of an 
object until it is required by 
a client. This is a variant of 
the Virtual Proxy. 


Complexity Hiding Proxy 

hides the complexity of 
and controls access to a 
complex set of classes. 

This is sometimes called 
the Facade Proxy for obvious reasons. 
The Complexity Hiding Proxy differs 
from the Facade Pattern in that the 
proxy controls access, while the Facade 
Pattern just provides an alternative 

interface. 




Habitat «r» the 切 the 
Java 


Field Notes ： please ddd youv obscwa-tiohS o( othev proxies ih the v/ild 
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crossword puzzle 



It’s been a LONG chapter. Why not unwind by doing a 
crossword, puzzle before it ends? 



Across 

I. Group of first CD cover displayed (two words) 

3. Proxy that stands in for expensive objects 

4. We took one of these to learn RMI 

7. Remote_ was used to implement 

the gumball machine monitor (two words) 

9. Software developer agent was being this kind 
of proxy 

II. In RMI, the object that takes the network 
requests on the service side 

14. Proxy that protects method calls from 
unauthorized callers 

15. A_proxy class is created at runtime 

16. Place to learn about the many proxy variants 

17. Commonly used proxy for web services (two 
words) 

18. In RMI, the proxy is called this 

19. The CD viewer used this kind of proxy 


Down 

2. Java's dynamic proxy forwards all requests to 
this (two words) 

5. Group that did the album MCMXC A.D. 

6. This utility acts as a lookup service for RMI 
8. Why 曰 roy couldn't get dates 

10. Similar to proxy, but with a different purpose 

12. Objectville Matchmaking gimmick (three 
words) 

13. Our first mistake: the gumball machine 

reporting was not_ 


490 


Chapter 11 














the proxy pattern 


I Tools for your design Toolbox 

\/ Your design toolbox is almost full; you’re prepared 
for almost any design problem that comes your way. 


QO \ 

but t'o« d n L 

以以二 . 

晌冰 ”- wds . 

七。 ☆ 碑 • 


'S 

yr\ 

t 




Ouv rvCY/ \>atW»r». 

A Pvo^y atts as a 
vc^cscr»*tatwc ^or 
ar\o 七 W object- 


i to 、 七 . 


扑 。 



to' 


mtvo\ a« ess 


BULLET POINTS 


■ The Proxy Pattern provides 
a representative for another 
object in order to control the 
client’s access to it. There 
are a number of ways it can 
manage that access. 

■ A Remote Proxy manages 
interaction between a client 
and a remote object. 

■ A Virtual Proxy controls access 
to an object that is expensive 
to instantiate. 

■ A Protection Proxy controls 
access to the methods of an 
object based on the caller. 

■ Many other variants of 
the Proxy Pattern exist 
including caching proxies, 
synchronization proxies, 
firewall proxies, copy-on-write 
proxies, and so on. 

■ Proxy is structurally similar to 
Decorator, but the two differ in 
their purpose. 

■ The Decorator Pattern adds 
behavior to an object, while a 
Proxy controls access. 

■ Java’s built-in support for Proxy 
can build a dynamic proxy 
class on demand and dispatch 
all calls on it to a handler of 
your choosing. 

■ Like any wrapper, proxies will 
increase the number of classes 
and objects in your designs. 
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Exercise solutions 


The NonOwnerlnvocationHandler works just like the 
OwnerlnvocationHandler, except that it allows calls to setHotOrNotRatingQ 
and it disallows calls to any other set method. Go ahead and write this 
handler yourself: 

import j ava. lang. reflect. * ; 

public class NonOwnerlnvocationHandler implements InvocationHandler { 
PersonBean person; 

public NonOwnerlnvocationHandler(PersonBean person) { 
this.person = person; 

} 

public Object invoke(Object proxy. Method method. Object[] args) 
throws IllegalAccessException { 

try { 

if (method. getName ()• startsWith (''get") ) { 

return method.invoke(person, args); 

} else if (method.getName () .equals (''setHotOrNotRatingQ) ) { 

return method.invoke(person, args); 

} else if (method.getName (>• startsWith (''set") ) { 

throw new IllegalAccessException(); 

} 

} catch (InvocationTargetException e) { 
e.printStackTrace(); 

} 

return null; 



Our ImageProxy class appears to have two states that are controlled 
by conditional statements. Can you think of another pattern that 
might clean up this code? How would you redesign ImageProxy? 

Use State Pattern: implement two states, ImageLoaded and ImageNotLoaded. Then put the code from 
the if statements into their respective states. Start in the ImageNotLoaded state and then transition to the 
ImageLoaded state once the Imagelcon had been retrieved. 


r Design class 
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Exercise solutions 


f 考 rpen your pencil 


While it is a little complicated, there isn’t much to creating a dynamic 
proxy. Why don’t you write getNonOwnerProxy(), which returns a 
proxy for the NonOwnerlnvocationHandler: 


PersonBean getNonOwnerProxy(PersonBean person) { 

return (PersonBean) Proxy.newProxylnstance( 
person.getClass().getClassLoader(), 
person.getClass().getlnterfaces(), 
new NonOwnerInvocationHandler(person)); 
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ready-bake code: cd cover viewer 


The code for the CP Cover Viewer 


package headfirst.proxy. virtualproxy; 

import java.net•*; 

import java.awt.*; 

import java.awt.event.*; 

import javax.swing.*; 

import java.util.*; 

public class ImageProxyTestDrive { 

ImageComponent imageComponent; 

JFrame frame = new JFrame (''CD Cover Viewer"); 

JMenuBar menuBar; 

JMenu menu; 

Hashtable cds = new Hashtable(); 

public static void main (String[] args) throws Exception { 

ImageProxyTestDrive testDrive = new 工 mageProxyTestDrive(); 



public ImageProxyTestDrive() throws Exception{ 

cds.put(''Ambient : Music for Airports","http://images.amazon.com/images/P/ 
B000003S2K.01.LZZZZZZZ.jpg^); 

cds.put(''Buddha Bar","http://images.amazon.com/images/P/B00009XBYK.01.LZZZZZZZ. 

jpg"); 

cds .put ( 、 'Ima’’ ， ’’http: / /images . amazon. com/images/P/B000005IRM. 01.LZZZZZZZ . jpg"); 
cds .put (''Karma’’ ， ’’http: //images . amazon. com/images/P/B000005DCB. 01.LZZZZZZZ . gif ,/r ); 
cds.put(''MCMXC A.D•"http://images.amazon.com/images/P/B000002URV.01.LZZZZZZZ. 

jpg"); 

cds.put(''Northern Exposure","http://images.amazon.com/images/P/B000003SFN.01. 
LZZZZZZZ.jpg"); 

cds.put(''Selected Ambient Works, Vol. 2","http://images•amazon•com/images/P/ 
B000002MNZ.01.LZZZZZZZ.jpg"); 

cds .put (''Oliver", ’’http: //www. cs . yale.edu/homes/f reeman-elisabeth/2004/9/01iver_ 
sm.jpg"); 


URL initialURL = new URL ( (String) cds .get (''Selected Ambient Works, Vol. 2")); 

menuBar = new JMenuBar(); 

menu = new JMenu (''Favorite CDs"); 

menuBar.add(menu); 

frame.setJMenuBar(menuBar); 
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for(Enumeration e = cds.keys(); e.hasMoreElements();) { 

String name = (String)e.nextElement(); 

JMenuItem menultem = new JMenuItem(name); 
menu.add(menultem); 

menultem.addActionListener(new ActionListener() { 

public void actionPerformed(ActionEvent event) { 

imageComponent.setlcon(new ImageProxy(getCDUrl(event.getActionCom- 


mand()))); 


frame.repaint(); 


})； 


// set up frame and menus 


Icon icon = new ImageProxy(initialURL); 

imageComponent = new ImageComponent(icon); 

frame.getContentPane().add(imageComponent); 

frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); 

frame.setSize(800,600); 

frame.setVisible(true); 


} 

URL getCDUrl(String name) { 
try { 

return new URL((String)cds.get(name)); 
} catch (MalformedURLException e) { 
e.printStackTrace(); 
return null; 
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ready-bake code: cd cover viewer 

The code for the CP Cover Viewer ： 

continued... 

package headfirst.proxy. virtualproxy; 

import java.net.*; 

import java•awt•*; 

import java.awt.event.*; 

import j avax.swing.*; 


B t% f t ^ v 

Ready-bal^ 
Code 


class ImageProxy implements Icon { 

ImageIcon imageIcon; 

URL imageURL; 

Thread retrievalThread; 
boolean retrieving = false; 

public ImageProxy(URL url) { imageURL = url; } 

public int getlconWidth() { 

if (imagelcon != null) { 

return imagelcon.getlconWidth(); 

} else { 

return 800; 

} 

} 

public int getlconHeight() { 
if (imagelcon != null) { 

return imagelcon.getlconHeight(); 

} else { 

return 600; 

} 

} 

public void paintlcon (final Component c, Graphics g, int x, int y) { 
if (imagelcon != null) { 

imagelcon.paintlcon(c, g, x, y); 

} else { 

g.drawstring (''Loading CD cover, please wait . . , x+300, y+190); 

if (!retrieving) { 

retrieving = true; 

retrievalThread = new Thread(new Runnable() { 

public void run() { 
try { 

imagelcon = new Imagelcon (imageURL, ''CD Cover"); 
c.repaint (); 

} catch (Exception e) { 
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e.printStackTrace(); 

} 

} 

})； 

retrievalThread.start(); 


package headfirst.proxy. virtualproxy; 
import java.awt.*; 
import j avax.swing.*; 


class ImageComponent extends JComponent { 
private Icon icon; 


public ImageComponent(Icon icon) { 
this.icon = icon; 

} 

public void setlcon (Icon icon) { 
this.icon = icon; 

} 

public void paintComponent(Graphics g) { 
super.paintComponent(g); 
int w = icon.getlconWidth(); 
int h = icon•getlconHeight(); 
int x = (800 - w)/2; 
int y = (600 - h)/2; 
icon.paintlcon(this, g, x, y); 

} 
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12 expound Patterns 


去 Patterns ♦ ▲ 

of Patterns * 



Who would have ever guessed that Patterns could work together? 

You’ve already witnessed the acrimonious Fireside Chats (and you haven’t even seen the Pattern 
Death Match pages that the editor forced us to remove from the book*), so who would have thought 
patterns can actually get along well together? Well, believe it or not, some of the most powerful 00 
designs use several patterns together. Get ready to take your pattern skills to the next level; it’s time 
for compound patterns. 

r send us email for a copy. 
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Working together 

One of the best ways to use patterns is to get them out of the house so they 
can interact with other patterns. The more you use patterns the more you’re 
going to see them showing up together in your designs. We have a special 
name for a set of patterns that work together in a design that can be applied 
over many problems: a compound pattern. "That’s right, we are now talking 
about patterns made of patterns! 

You’ll find a lot of compound patterns in use in the real world. Now that 
you’ve got patterns in your brain, you’ll see that they are really just patterns 
working together, and that makes them easier to understand. 

We’re going to start this chapter by revisiting our friendly ducks in the 
SimUDuck duck simulator. It’s only fitting that the ducks should be here 
when we combine patterns; after all, they’ve been with us throughout the 
entire book and they’ve been good sports about taking part in lots of patterns. 
The ducks are going to help you understand how patterns can work together 
in the same solution. But just because we’ve combined some patterns doesn’t 
mean we have a solution that qualifies as a compound pattern. For that, it 
has to be a general purpose solution that can be applied to many problems. 
So, in the second half of the chapter we’ll visit a real compound pattern: 
that’s right, Mr. Model-View-Controller himself. If you haven’t heard of 
him, you will, and you’ll find this compound pattern is one of the most 
powerful patterns in your design toolbox. 



Patterns are often usect togfetker anct 
comtinect witkin tke same ctesigfn solution. 


A compounct pattern combines two or 
more patterns into a solution tkat solves a 
recurring or general prottem. 


龜 
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Puck reunion 

As you’ve already heard, we’re going to get to work with the ducks again. This time the ducks 
are going to show you how patterns can coexist and even cooperate within the same solution. 

We’re going to rebuild our duck simulator from scratch and give it some interesting capabilities 
by using a bunch of patterns. Okay, let’s get started... 


① First, we'll create a Quackable interface. 

Like we said, were starting from scratch. This time around, the Ducks are 
going to implement a Quackable interface. That way well know what things 
in the simulator can quackQ - like Mallard Ducks, Redhead Ducks, Duck 
Calls, and we might even see the Rubber Duck sneak back in. 


public interface Quackable 
public void quack(); 




② 


Now, some Ducks that implement Quackable 

What good is an interface without some classes to implement it? Time to 
create some concrete ducks (but not the u lawn art” kind, if you know what 
we mean). 



public class MallardDuck implements Quackable { 
public void quack() { 

System, out .println (''Quack"); 


v /辦 

MaWavd 


} 


public class RedheadDuck implements Quackable 
public void quack() { 

System, out .println (''Quack /’）； 

} 


We’ve yt "to sow»C v3vi3'tio^ 
of i-f vjc "tWis to be By\ 

"m'tcv-cstmg simulatov- 
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adding more ducks 


This wouldn't be much fun if we didn't add other kinds of Ducks too. 

Remember last time? We had duck calls (those things hunters use, they 
are definitely quackable) and rubber ducks. 


public class DuckCall implements Quackable 
public void quack() { 

System, out .println (''Kwak ,/r ); 

} 


PudCall bul doesn’t 

sound <\uitc like veal 


public class RubberDuck implements Quackable 
public void quack() { 

System.out .println (''Squeak"); 

} 


A Rubbcv-Pudk tKat makes a 
squeak y/Kcn it <^uadks. 


③ Okay, we've got our ducks; now all we need is a simulator. 

Let’s cook up a simulator that creates a few ducks and makes sure their 
quackers are working... 




Hevc s ouy- ' 


cbV^od "bo 


public class DuckSimulator { 

public static void main(String[] args) { 

DuckSimulator simulator = new DuckSimulator (); 之 
simulator.simulate(); <^~ 




如 t trtait a simula-bor 
dr>a tall 
s\mula-tcO wetW. 


void simulate () { 


Quackable mallardDuck = new MallardDuck(); 
Quackable redheadDuck = new RedheadDuck(); 
Quackable duckCall = new DuckCall(); 
Quackable rubberDuck = new RubberDuck(); 



\A/e need some (Kks, ? 
V, e ve vje tveale o«e <A- 
eatV> (^vAatkable... 


System, out .println (''\nDuck Simulator"); 


simulate(mallardDuck); 
simulate(redheadDuck); 
simulate(duckCall); 
simulate(rubberDuck); 

} 

void simulate(Quackable duck) 
duck.quack(); 


... ^ s'iwulatc 

^ oi\t- 

HcvC QVgvlodd "BlC sirwuld'tc 
met^odi to sirwula-tc jus-t oy\C 



fT' y Hcvc y/C let ^olymor^Kism do i*ts nr»aji ^： y\o 

ma 七七 ev y/Kai k'rnd o( ^uddkdble jc*ts passed in, 
•tKc simulatcO mciKod asks it to <\ua^k. 
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wc 



I File Edit Window Help ItBetterGetBetterThanThis 

— 

% java DuckSimulator 


Duck Simulator 


Quack 


Quack 


Kwak 


Squeak 


% 



new all the same <$«atkaWe 

mW-fate, tV>e«v — ⑽山妇⑽ 
allo>. -tv»e«- -to ovm 叫 . 

It looks like everything is working; so far, so good. 

When ducks are around, geese can't be far. 

Where there is one waterfowl, there are probably two. Here's a Goose 
class that has been hanging around the simulator. 


public class Goose { 

public void honk() { 

System, out • println ( 、 'Honk"); 

} 



A ^OOSC is a Kohkcv-, 
y\ot a <^uadkcv-. 


Let’s say we wanted to be able to use a Goose anywhere we’d want to use a Duck. After all, geese 
make noise; geese fly; geese swim. Why can’t we have Geese in the simulator? 

What pattern would allow Geese to easily intermingle with Ducks? 
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goose adapter 


⑤ We need a goose adapter. 

Our simulator expects to see Quackable interfaces. Since geese 
aren’t quackers (theyre honkers), we can use an adapter to adapt 
a goose to a duck. 


public class GooseAdapter implements Quackable 
Goose goose; 

public GooseAdapter (Goose goose) { ^ _ The 6onsWto\r "takes the 

^ this. goose = goose; joose we 5 o'm 5 io ada ? l- 

l/VKcn ^ua^k is called ； tKc ta\\ is dclcja-tcd 
乇 。 -tKc goose’s Ko^kO mctKod- 

Now geese should be able to play in the simulator, too. 

All we need to do is create a Goose t wrap it in an adapter that 
implements Quackable, and we should be good to go. 


public void quack() 
goose.honk(); 

} 



m tW.s tase '.s ( 5 >*atkaWe. 


public class DuckSimulator { 

public static void main(String[] args) { 

DuckSimulator simulator = new DuckSimulator(); 
simulator.simulate(); 

} 

void simulate() { 

Quackable mallardDuck = new MallardDuck(); 

Quackable redheadDuck = new RedheadDuck(); 

Quackable duckCall = new DuckCall(); 

Quackable rubberDuck = new RubberDuck()/ 

Quackable gooseDuck = new GooseAdapter(new Goose()); 

System, out .println (''\nDuck Simulator : With Goose Adapter"); 


We ">ake a ^oose -t^at at 
a W 狀 a ?? 岣七“。攸 

b ：. 4-w, 6ooseAdap-tev-. 


simulate(mallardDuck); 
simulate(redheadDuck); 
simulate(duckCall); 
simulate(rubberDuck); 
simulate(gooseDuck); 



Or\U 6\oosc is brtai 

i-t jus-t like olV«ev dwtk <5uadkables. 


void simulate(Quackable duck) { 
duck.quack(); 


504 


Chapter 12 




compound patterns 


Now let's give this a quick run_ 

This time when we run the simulator, the list of objects passed 
to the simulateQ method includes a Goose wrapped in a duck 
adapter. The result? We should see some honking! 


Theve’s iKc goose/ Now iKc 


'rcs-t o\ iKc Dudks. . 


File Edit Window Help GoldenEggs 


% java DuckSimulator 

Duck Simulator : With Goose Adapter 

Quack 

Quack 

Kwak 

Squeak 

Honk 


Quacl^plogy 


Quackologists are fascinated by all aspects of Quackable behavior. One 
thing Quackologists have always wanted to study is the total number of 
quacks made by a flock of ducks. 

How can we add the ability to count duck quacks without having to 
change the duck classes? 

Can you think of a pattern that would help? 


J- Bv-cwcv-, 

Pav-k a^d 

^uadkolojis-fc 
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duck decorator 


Were going to make those Quackologists happy and give 
them some quack counts. 

How? Let's create a decorator that gives the ducks some new 
behavior (the behavior of counting) by wrapping them with a 
decorator object. We won’t have to change the Duck code at all. 


6JuatkCou^v »s a dctov-atov 


public class QuackCounter implements Quackable 
Quackable duck; 

static int numberOfQuacks; / <_ 


Like y/i-tK y/c need 七。 

mtev-fadc. 

got an ms-tandc vaviablc 
七 。 \iold or\ "to 
y/cVc dedovatmg. 


public QuackCounter (Quackable duck) 
this.duck = duck; 

} 



Ahd wcVc douhiihj f\LL 
一 SO well use ^ s-tatid 

variable to keep tvadk. 




public void quack() { 

duck.quack(); 
numberOfQuacks++; 

} 


public static int getQuacks() { 
return numberOfQuacks; 

} 


3^-t -the \rc-fcv-chdc io -the 

<$uadkablc wcVc dcdov-aii h g i h 
"the dohs-tv-ud*tov. 

ihe ^ 


adding o»^c o-tKcv- mrtKod 
"to the dedov-atov. This s-tatid 
method jus 七 \rc-tuv-K»s "the humbev- 

o( ^uadks -that Kavc odduvved 
•m all ^uadkables. 
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⑧ 


We need to update the simulator to create decorated ducks. 


Now, we must wrap each Quackable object we instantiate in a 
QuackCounter decorator. If we don’t, well have ducks running 
around making uncounted quacks. 


public class DuckSimulator { 

public static void main(String[] args) { 

DuckSimulator simulator 二 new DuckSimulator() 
simulator.simulate(); 


Eddh "tirwc wc 3 

^uatkablc ； wc y/vap i£ 
with a hew dcdovatov. 


void simulate() { 

Quackable mallardDuck = new QuackCounter(new MallardDuck()); 
Quackable redheadDuck = new QuackCounter(new RedheadDuck()); 
Quackable duckCall = new QuackCounter(new DuckCall()); 
Quackable rubberDuck = new QuackCounter(new RubberDuck()); 
Quackable gooseDuck = new GooseAdapter(new Goose()); 


} 


System, out .println (''\nDuck Simulator : With Decorator"); 


simulate(mallardDuck); 
simulate(redheadDuck); 
simulate(duckCall); 
simulate(rubberDuck); 
simulate(gooseDuck); 


Tk park told us he did^i 

wah-t io douh 七 jeese honks, so we 
dov\i dedovate it 


System, out .println (''The ducks quacked '' + 

QuackCounter.getQuacks() 


6 Hcvcs ^nect viC 

times") ; bc^av'»ov -fov- 

^uatkoloys-ts. 


void simulate(Quackable duck) 
duck.quack(); 

} 


tV,a^ V, e «; 

objects arc sfcll 


OVAt〆 ！ 



tOVA^ V CSC - 


| File Edit Window Help Decorated Eggs 

■ 

% java DuckSimulator 


Duck Simulator : With Decorator 


Quack 


Quack 


Kwak 


Squeak 


Honk 


4 quacks were counted 


% 
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duck factory 



⑭ We need a factory to produce ducks! 

Okay, we need some quality control to make sure our ducks get wrapped. 

Were going to build an entire factory just to produce them. The factory 
should produce a family of products that consists of different types of 
ducks, so were going to use the Abstract Factory Pattern. 

Let’s start with the definition of the AbstractDuckFactory ： 

We v e 

仔 at subclasses W.II 
trtait W W ， V»cs. 

public abstract class AbstractDuckFactory { 

public abstract Quackable createMallardDuck(); 
public abstract Quackable createRedheadDuck(); 
public abstract Quackable createDuckCall(); 
public abstract Quackable createRubberDuck(); 

} 

rwrtKod dvcatcs k'md o( dudk- 
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Let’s start by creating a factory that creates ducks without decorators, 
just to get the hang of the factory ： 




public class DuckFactory extends AbstractDuckFactory { 


public Quackable createMallardDuck() 
return new MallardDuck(); 

} 

public Quackable createRedheadDuck() 
return new RedheadDuck(); 

} 

public Quackable createDuckCall() { 
return new DuckCall(); 

} 


DudkPat 七 ovy extends tKc 
abs-tva^t -fa^-tovy. 

method creaks a • 七 . 
a k.md J 6!«atkaWe. 

TV, e atW —ut 七.—了 
a 6!»atkaW e ' 


public Quackable createRubberDuck() 
return new RubberDuck(); 

} 


Now lefs create the factory we really want, the CountingDuckFactory ： 




public class CountingDuckFactory extends AbstractDuckFactory { 


public Quackable createMallardDuck() { 

return new QuackCounter(new MallardDuck()); 


public Quackable createRedheadDuck() { 

return new QuackCounter(new RedheadDuck()); 


public Quackable createDuckCall() { 

return new QuackCounter(new DuckCall()); 


public Quackable createRubberDuck() { 

return new QuackCounter(new RubberDuck()); 



also ey •七 

abstvat 七 ^ attov'y- 


EadK mctKod >wvaps -tKc 
6^ua^kable WiiK -tKc <^uadk 
douhtmg dedova-tov. TKc 
simula-tov- v/ill r\cvcv kr\ov/ 
■tKc di-f-fcvc^dc ； ii jus-t 
jcb badk a ^ua^kable- 

Bu-t ho>w ouv va^jevs dart 

be suve -tKai all <\uadks avc 
bc'mj douh-ted- 
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families of ducks 


⑪ Let's set up the simulator to use the factory. 

Remember how Abstract Factory works? We create a polymorphic method 
that takes a factory and uses it to create objects. By passing in different 
factories, we get to use different product families in the method. 

Were going to alter the simulateQ method so that it takes a factory and 
uses it to create ducks. 







public class DuckSimulator { 

public static void main(String[] args) { 

DuckSimulator simulator 二 new DuckSimulator(); 
AbstractDuckFactory duckFactory = new CountingDuckFactory(); 


simulator.simulate(duckFactory); 


void simulate(AbstractDuckFactory duckFactory) { 

Quackable mallardDuck = duckFactory.createMallardDuck(); 
Quackable redheadDuck = duckFactory.createRedheadDuck(); 
Quackable duckCall = duckFactory.createDuckCall(); 

Quackable rubberDuck = duckFactory.createRubberDuck(); 
Quackable gooseDuck = new GooseAdapter(new Goose()); 

System, out .println (''\nDuck Simulator : With Abstract Factory"); 


to〆 六） 

如 s 、 一 atcU 



TKc simula-tcO 
mctKod iakes 
AbsivadtDudkFad-tov-'y 
and uses i-t to dveate 
dudks vatKcv iKah 
'ms-tahiiaiihj iKcm 
divedJy. 


} 


simulate(mallardDuck); 
simulate(redheadDuck); 
simulate(duckCall); 
simulate(rubberDuck); 
simulate(gooseDuck); 



System, out .println (''The ducks quacked '' + 

QuackCounter.getQuacks() 
' 、 times"); 



/Nothing Kcvc/ 

Same ol’ to&t- 


} 


void simulate(Quackable duck) { 
duck.quack(); 
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flock of ducks 



Ah, he wants to manage a 
flock of ducks. 


Here’s another good question from Ranger Brewer: 
Why are we managing ducks individually? 


TWis vcv-7 
ma^ayablc! 



Quackable mallardDuck = duckFactory.createMallardDuck(); 
Quackable redheadDuck = duckFactory.createRedheadDuck(); 


Quackable duckCall = duckFactory.createDuckCall(); 
Quackable rubberDuck = duckFactory.createRubberDuck(); 
Quackable gooseDuck = new GooseAdapter(new Goose()); 


simulate 

simulate 

simulate 

simulate 

simulate 


(mallardDuck); 
(redheadDuck); 
(duckCall); 
(rubberDuck); 
(gooseDuck); 


What we need is a way to talk about collections of 
ducks and even sub-collections of ducks (to deal with 
the family request from Ranger Brewer). It would 
also be nice if we could apply operations across the 
whole set of ducks. 

What pattern can help us? 
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⑫ Let's create a flock of ducks (well, actually a flock of Quackables). 

Remember the Composite Pattern that allows us to treat a collection of 
objects in the same way as individual objects? What better composite 
than a flock of Quackables! 


Let’s step through how this is going to work ： 



| ea ^ e | eB . e «-b a« 


public class Flock implements Quackable { 
ArrayList quackers = new ArrayList(); 

public void add(Quackable quacker) { 
quackers.add(quacker); 



IVcVc Bv\ Av'V-ayLis-t mside 
Flodk -to Hold iKc <5uadkablcs 
■tKat belong -to "tKc Flodk. 

_ TV^c addiO method adds a 

6Jua6kablc b> *tV>c Flotk. 


} 


public void quack() { 

Iterator iterator = quackers.iterator(); 
while (iterator.hasNext()) { 

Quackable quacker = (Quackable)iterator.next(); 
quacker.quack(); 

} 


r , u 一 l 丄匕 ^all quadkO 




Ijp Cl^S' 


e 


Did you notice that we tried to sneak a Design Pattern by 
you without mentioning it? 


public void quack() { 

Iterator iterator = quackers.iterator(); 
while (iterator.hasNext()) { 

Quackable quacker = (Quackable)iterator.next(); 
quacker.quack(); 



TV^cvc \i »s! T\\t IWa-tov 
?aiicYr\ ai v/ov-k| 


} 



} 


you are here ► 513 





duck composite 


⑫ Now we need to alter the simulator. 

Our composite is ready; we just need some code to round up the 
ducks into the composite structure. 


public class DuckSimulator { 

// main method here _ Cvca-tc all ttc 

^uadkablcs, jus 七 

void simulate (AbstractDuckFactory duckFactory) { \\\^ t before- 

Quackable redheadDuck = duckFactory.createRedheadDuck(); 

Quackable duckCall = duckFactory.createDuckCall(); 

Quackable rubberDuck = duckFactory.createRubberDuck(); 

Quackable gooseDuck = new GooseAdapter(new Goose()); ) 

System, out .print In (''\nDuck Simulator : With Composite - Flocks ”）； 


} 


Flock flockOf Ducks = new Flock (); 

flockOfDucks . add (redheadDuck); 
flockOf Ducks . add (duckCall); 
flockOf Ducks . add (rubberDuck); 
flockOf Ducks . add (gooseDuck); 


Flock flockOfMallards = new Flock (); 



Fivs-t v/c a Flodk, Bv\d 

load ii y/i-tK 6^uadkablcs. 


pUk Mallards. 


Quackable 

Quackable 

Quackable 

Quackable 


mallardOne = duckFactory.createMallardDuck(); 
mallardTwo = duckFactory.createMallardDuck(); 
mallardThree = duckFactory.createMallardDuck(); 
mallardFour = duckFactory.createMallardDuck(); 



ttcvc y/cVc 
tvcatmj a 
little -family o-f 
mallards... 


flockOfMallards . add (mallardOne); 
flockOfMallards . add (mallardTwo); 
flockOfMallards . add (mallardThree); 
flockOfMallards . add (mallardFour); 


flockOf Ducks . add (flockOfMallards); 



a did m3 tKcm -to iKc 

Flodk o-f mallards. 


Then y/c add the Flodk o( 
mallav-ds -to -the ma'm -flodk. 


System, out .println (''\nDuck Simulator : 
simulate (flockOfDucks); 


Whole Flock Simulation ”）； 

- Let’s -tes-t out the Ch-tivc Flodk/ 


System, out .println (''\nDuck Simulator : 
simulate (flockOfMallards); 


Mallard Flock Simulation">; 



Theh let’s jus 七 -test ou*t *tKc mallavd’s Flodk. 


System, out .println (''\nThe ducks quacked 


QuackCounter.getQuacks() 
times"); 


} 



Finally, lets jive the 

夕 uadkologis 七七 he da*ta. 


void simulate(Quackable duck) 
duck.quack(); 

} 


No-tKihj heeds -to Kcvc, a Flodk is a 夕 ua 匕 kable/ 
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compound patterns 


Let’s give it a spin... 


I File Edit Window Help FlockADuck 


% java DuckSimulator 

Duck Simulator : With Composite - Flocks 
Duck Simulator: Whole Flock Simulation 
Quack 

Kwak 广 ttcrcs A " 七 \\ocV- 

Squeak 

Honk 

Quack 

Quack 

Quack 

Quack 




Quack 

Quack 

Quack 

Quack 


Simulator : Mallard Flock Simulation 
~^ ^allav-ds. 

TV>c data looks 
C aood (vcwcmbcv 
^oosc docs^t 

The ducks quacked 11 times — tour ' 七⑷ 


Safety versus transparency 


You might remember that in the Composite Pattern chapter the composites (the Menus) and the leaf nodes 
(the Menultems) had the same exact set of methods, including the add() method. Because they had the 
same set of methods, we could call methods on Menultems that didn’t really make sense (like trying to add 
something to a Menultem by calling add()). The benefit of this was that the distinction between leaves and 
composites was transparent: the client didn’t have to know whether it was dealing with a leaf or a composite; 
it just called the same methods on both. 

Here, we’ve decided to keep the composite's child maintenance methods separate from the leaf nodes: that 
is, only Flocks have the add() method. We know it doesn’t make sense to try to add something to a Duck, 
and in this implementation, you can’t. You can only add() to a Flock. So this design is safer- you can’t call 
methods that don’t make sense on components - but it’s less transparent. Now the client has to know that a 
Quackable is a Flock in order to add Quackables to it. 

As always, there are trade-offs when you do 00 design and you need to consider them as you create your 
own composites. 



you are here ► 


515 





duck observer 



The Composite is working 
great! Thanks! Now we have the 
O f opposite request ： we also need to 
track individual ducks. Can you give 
us a way to keep track of individual 
duck quacking in real time? 


Can you say “observer ? 9 

It sounds like the Quackologist would like to observe individual 
duck behavior. That leads us right to a pattern made for observing 
the behavior of objects: the Observer Pattern. 




First we need an Observable interface. 


Remember that an Observable is the object being observed. An Observable 
needs methods for registering and notifying observers. We could also have 
a method for removing observers, but we 11 keep the implementation simple 
here and leave that out. 



fijuatkObsevvaWe is 如 mtev^ate 
七 b 七 fijwatkaWes Should 叫一 
^ -tV>eY warvt -b be Revved. 


public interface QuackObservable { 

public void registerObserver(Observer observer); 
public void notifyObservers(); 




I 七 3 lso has d method -Pov* 
"the obscirvcvs. 


It Kas a method -fov- vcjis-tcv'mj 
Observers. object implcmchtmj 

the Observer mtev-fade tav\ listen 

"to <^uadks. dc-fihc "the Obscwcr 

it^-tev-fade m a sec. 


Now we need to make sure all Quackables implement this interface... 


public interface Quackable extends QuackObservable 
public void quack(); 

} 


So, we the ^uadkable 

mtcv-Padc with <$uadkObscv-vcv. 
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⑮ Now, we need to make sure all the concrete 
classes that implement Quackable can handle 
being a QuackObservable. 

We could approach this by implementing registration and 
notification in each and every class (like we did in Chapter 
2). But were going to do it a little differently this time ： 
were going to encapsulate the registration and notification 
code in another class, call it Observable, and compose it 
with a QuackObservable. That way we only write the real 
code once and the QuackObservable just needs enough 
code to delegate to the helper class Observable. 

Lefs start with the Observable helper class... 


Stop looking at 
me. You're making 
me nervous! 


o 

o 





Obs e ,vaW e 311 

a _kaWe «« 如七 。 k a? 如丁 abl:. 




public class Observable implements QuackObservable 

ArrayList observers = new ArrayList(); 

QuackObservable duck; 

public Observable(QuackObservable duck) { 
this.duck = duck; 

} 

public void registerObserver(Observer observer) { 
observers.add(observer); 

} 

public void notifyObservers() { 

Iterator iterator = observers.iterator (); 
while (iterator.hasNext()) { 

Observer observer = (Observer)iterator.next(), 
observer.update(duck); 

, } 


Observable mus-t 6Juadk^)bscv-vablc 

bcdausc -tKcsc av-c -tKc same mctKod dalls 
tKai av-c jo'mj -to be delegated to it 

|“V>e to 怕 trufU 吃 

passed c 

tKa-b is "t Ws ob j et 七七。 


一 a— observable beV.av.ov- 

(VtkouUV^ 。 以 Y() 
belov .； voull see tV»a 七 a 
« 為 Obervable ?asses 

•tWis objet-t alor>5 so ^a-t 
JoierMtr knows >wWitV> objeft is 

HevVs iKc todt -Pov 
vegistev-mj an obscv-vcv-. 


^[r\d "tKc toAt -fov do'mj 
■tKc noti-fitatior>s. 


Movj lets sec Kov/ a ^ua^kable dlass uses tKis Kdfcv... 
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quack decorators are observables too 


⑭ Integrate the helper Observable with the Quackable classes. 

This shouldn’t be too bad. All we need to do is make sure the Quackable classes 
are composed with an Observable and that they know how to delegate to it. After 
that, they re ready to be Observables. Here's the implementation of MallardDuck; 
the other ducks are the same. 


public class MallardDuck implements Quackable { V^as 

Observable observable; - 〆 Observable mslarvtc vav'»aWc- 


public MallardDuck() { 

observable = new Observable(this); 

} 


public void quack() { 

System. out • println (''Quack/'); 
notifyObservers(); 

} 


In the dohs-tvud-tov, wc dveate ah 
Observable a^d pass i-t a vc-fcvchdc 
七 。七 he /VJallav-dDudk object 

- iVKch wc <^uadk, y/c 

heed to Irt "tKc 
observes khow abou-t i-fc. 


public void registerObserver(Observer observer) { 
observable.registerObserver(observer); 

} 


public void notifyObservers() { 

observable.notifyObservers(); 

} 



Hcve’s ouv two ^uadkObscwablc 
methods. Hohu that v/c just 

ddcgaic -to -tKc Kdpcv-. 


e^arpen your pencil 

We hav 


We haven’t changed the implementation of one Quackable, the QuackCounter 
decorator. We need to make it an Observable too. Why don’t you write that one: 
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@ Were almost there! We just need to work on the Observer side 
of the pattern. 

WeVe implemented everything we need for the Observables; now we 
need some Observers. Well start with the Observer interface ： 

r 卜 o\>^ inMate t 

as one ^od, updaieO, which 
二 P:«ed ihe 知邮 b Wva bl e 
that _ s ㈣ ki« 3 . 

public interface Observer { 

public void update(QuackObservable duck); 

} 


Now we need an Observer ： where are 
those Quackologists?! 


I/Vc need io Observable 'm-tc\rfadc or else 

y/c y/oni be able to rosier a 公 uadkObsmablc. 

\ 

public class Quackologist implements Observer { 


} 


public void update(QuackObservable duck) { 

System, out .println (''Quackologist : '' + duck + '' just quacked."); 



— e ; 4 j-t h 
二卜 


OhC 

c 
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flock composites are observables too 



What if a Quackologist wants to observe an entire flock? What does that mean 
anyway? Think about it like this: if we observe a composite, then we're observing 
everything in the composite. So, when you register with a flock, the flock 
composite makes sure you get registered with all its children (sorry, all its little 
quackers), which may include other flocks. 

Go ahead and write the Flock observer code before we go any further... 
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compound patterns 


⑭ We're ready to observe. Let's update the 
simulator and give it try ： 


public class DuckSimulator { 

public static void main(String[] args) { 

DuckSimulator simulator = new DuckSimulator(); 
AbstractDuckFactory duckFactory = new CountingDuckFactory(); 

simulator.simulate(duckFactory); 


void simulate(AbstractDuckFactory duckFactory) { 


// create duck factories and ducks here 
// create flocks here 


System, out .println (''\nDuck Simulator : With Observer"); 


Quackologist quackologist = new Quackologist(); 
flockOfDucks.registerObserver(quackologist); 


simulate (flockOfDucks); 

System, out .println (''\nThe ducks quacked '' + 
QuackCounter.getQuacks() 



All >«e do V>eve is tvea-te a 
( 5 vAatkolo 5 .s-t a«a set W.m as 

an obsevvev -tV>e Aotk. 


TVis 'time wc^ll we 


times"); 


just Sirwula-tc 


civtivc -Plodk. 


void simulate(Quackable duck) 
duck.quack(); 


i-cis jive i-t a try at\d 

see Kow i-fc v/o\rks/ 
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the duck finale 


This is the big finale. Five, no, six patterns have come together to create 
this amazing Duck Simulator. Without further ado, we present the 
DuckSimulator! 


| File Edit Window Help DucksAreEverywhere 

I 

% java DuckSimulator 

Duck Simulator: With Observer 


Quack 

c^uadk, matter 
〆 ~ N Aa 七 kmd 

Quackologist: Redhead Duck just quacked. . 

Kwak 

cy>a6k it 七 he 

Quackologist: Duck Call just quacked. 

obscwcv 3 

Squeak 


Quackologist: Rubber Duck just quacked. 

Honk 

Quackologist: Goose pretending to be a Duck 

just quacked. 

Quack 

Quackologist: Mallard Duck just quacked. 
Quack 

Quackologist: Mallard Duck just quacked. 
Quack 

Quackologist: Mallard Duck just quacked. 
Quack 

Quackologist: Mallard Duck just quacked. 


The Ducks quacked 7 times. 

/ <^uadkolojis-t still 

% 

gets Kis doubts. 


Duml?C^ii©stiPiis 


So this was a compound pattern? 

No, this was just a set of patterns 
working together. A compound pattern is a 
set of a few patterns that are combined to 
solve a general problem. We’re just about 
to take a look at the Model-View-Controller 
compound pattern; it’s a collection of a few 
patterns that has been used over and over in 
many design solutions. 


So the real beauty of Design 
Patterns is that I can take a problem, and 
start applying patterns to it until I have a 
solution. Right? 

Wrong. We went through this 
exercise with Ducks to show you how 
patterns can work together. You’d never 
actually want to approach a design like we 
just did. In fact, there may be solutions to 
parts of the duck simulator for which some 
of these patterns were big time overkill. 


Sometimes just using good 00 design 
principles can solve a problem well enough 
on its own. 

We’re going to talk more about this in the 
next chapter, but you only want to apply 
patterns when and where they make 
sense. You never want to start out with the 
intention of using patterns just for the sake 
of it. You should consider the design of the 
DuckSimulator to be forced and artificial. 
But hey, it was fun and gave us a good 
idea of how several patterns can fit into a 
solution. 


522 Chapter 12 




compound patterns 


What did we do? 


We started with a bunch of Quackables … 

A goose came along and wanted to act like a Quackable too. So we 

used the Adapter Pattern to adapt the goose to a Quackable. Now, you can call quack() on a 
goose wrapped in the adapter and it will honk! 

Then, the Quackologists decided they wanted to count quacks. So we 

used the Decorator Pattern to add a QuackCounter decorator that keeps track of the number 
of times quack() is called, and then delegates the quack to the Quackable it’s wrapping. 

But the Quackologists were worried they’d forget to add the 
QuackCounter decorator. So we used the Abstract Factory Pattern to create ducks 
for them. Now, whenever they want a duck, they ask the factory for one, and it hands back 
a decorated duck. (And don’t forget, they can also use another duck factory if they want an 
un-decorated duck!) 


We had management problems keeping track of all those ducks and 
geese and quackables. So we used the Composite Pattern to group quackables 
into Flocks. The pattern also allows the quackologist to create sub-Flocks to manage duck 
families. We used the Iterator Pattern in our implementation by using java.util's iterator in 
ArrayList. 

The Quackologists also wanted to be notified when any quackable 
quacked. So we used the Observer Pattern to let the Quackologists register as Quackable 
Observers. Now they’re notified every time any Quackable quacks. We used iterator again 
in this implementation. The Quackologists can even use the Observer Pattern with their 
composites. 
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duck’s eye view 


A 妙必 duck's eye view: the class diagram 

We’ve packed a lot of patterns into one small duck simulator! Here’s the big picture of what we did: 
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compound patterns 
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a” Obscwablc 一七 ⑽七 . 
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㈣ 
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«interface» 

L ： _ i 

QuackObservable 



registerObserver( Observer) 



notifyObserversf) 


\f 


_1 


mstandc of Observable 
to keef tvadk o*f i^civ 
obsewevs and noti-fy them 

v/Keyt 七 k 公 uadkablc <\uatks 


《 interface 》 

Quackable 


quack() 


iL 


MallardDuck 


RedheadDuck 


RubberDuck 

quack() 

registerObserver(Observer) 

notifyObservers() 


V^ave 七…。 

fijuatkablcs ： dutks a^d 
。七七、 
^uadkable behavior ： hkc *tV>c 
^ooscAda\>W, ^a\>s a 

^oose a^d makes it look l'«kc 
a ^uatkablci PUk, is 
a fijuatkablc Composite, a^d 
6JuatkCour\tcv-, >wWiA adds 
bcV>av'»ov to ^uatkablcs. 



Observable 


ArrayList observers 
QuackObservable duck 


registerObserver(Observer) 

notifyObservers() 


GooseAdapter 

Goose goose 


quack() 

registerObserver(Observer) 

notifyObservers() 

Flock 


This 外七 d- 


ArrayList ducks 


add(Quackable) 

quack() 

registerObserver(Observer) 

notifyObservers() 


... and "tWis 
Com^osi-tc- 


QuackCounter 

Quackable duck 

getQuacks() 

quack() 

registerObserver(Observer) 

notifyObservers() 


... and 七 his 、 
Pcdova-tov- ^ 
all att like 
^uadkablcsj 
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the model view controller song 


The King of Compound Patterns 

If Elvis were a compound pattern, his wawe would be Model-Yiew-Cowtrollei ： 
and he'd be smgmg a little song like this... 


A^lodcl, l/icv/, Coh-tvollcv 
Lyrics a^d rwusit by James Pcrwpscy. 

tA\/C^ a pavadigrw -for -Pa£.*tovmg youv toAt 

m*to -fu»r\^-tior>al sejrweivts, so youv b\r3'm does r>o*t explode- 

To achieve vcusability, you gotta keep -those boundaries 
dear\ 

Model oy\ "the oy\C side^ \/icy/ or> "the o-thev, "the 
Cor>*tvollcv s *m between. 



^ /V|odcl 


Model \/icy/, rt^s go*t "thv-cc I aye vs like Orcos do 
/V|odcl \/icv/ Co>vbrolkv 

A^lodcl \/icv/) A^lodcl \/iew, A^lodcl \/icv/ Co»vbrollev 
A^lodcl objects vcpv-csch-t your applications vaisor\ ditbrt 

Cus-tom objects -that 乙 oivta’m daia^ logi 。 ar\d c-t Cetera 

Y^ou c.vca*tc 乙 us*torw classes, m youv app^s problem domam 
you t^v\ tlioosc "to reuse "tlicrw v/i-th all "the viev/s 
bu-t -the model objects stay -the sa^c. 


Y^ou £.dr> model 3 *thv-o"t"tlc 3r>d 3 ma^i-fold 
Model "the -toddle of a "bwo ycav old 
A^lodcl 3 bottle of -fmc Ciiav-dohr>ay 
A^lodcl all the glottal s-tops people say 
A^lodcl "the £.oddlm^ <^P boil'm^ eggs 
V^ou model the v/addle m Healeys le^s 

Mode I \/'icyj, you model dll "the models -tha-t pose (or 
A^lodcl \/icy/ Cor>*t\rollcv 

\/icv/ ofejjc^-ts -tchd -to be 乙 oivbroU used "to display a^d edi 七 
CoCod!^ go*t 3 lo*t of "those, v/cll v/ri"bteh 七 。 its tvedit 
Take 3y) KSTcx.'tl/icv/, hand i*t any old Ur>itodc s*brmg 
The user i»vt 伙 a 乙七 i"t, i 七乙扣 hold rwos 七 ar\ythmg 

Bu 七 "the view dov\{, kr>ov/ abou-t "the A^lodcl 
Tha*t s-tirmg 乙 ould be d phor>c r>urwbc\r or "the v/orks o( 

A'ris-totlc 

^ccp "the touplmg loose 

a^d so achieve a massive level o( vcusc 

Model l/icw, all vchdcvcd vevy W\tc\y \v\ / \«\ua blue 
Model \/icy/ Corrbrollcv 

yWire pvobably v/or>dcv-ir>g y\o^j 
YouVe pvobably y/ohdev-mg hov/ 

Data -floy/s bc*ty/ccr\ Model a^d \/iew 
The Cor>*t\rollcv has "to mediate 
Between layers 乙 state 
To syr\tli\ror>iz« "the data o( *thc "tv/o 
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It pulls dhd pushes cvcvy value 


I sct\{, a Tc^-tFidd S-tv'mg\/aluc. 


compound patterns 


Model \/icy/| mad props -to -the Smalltalk dvcwf 
tAoAt\ \/icv/ Cor>*tvollcv 


A^lodcl its pvor>ouh£.cd 0\\ 0\\ hot Ooo Ooo 
tAoAt\ \/icy/ Coivbrollcv 


Theve s a li-ttlc Ic-ft to tliis s-tovy 
A -Pev/ rwovc miles upor> "this voad 
Nobody scenes -to yt rv»u£.h glory 
Fv-orw wvit'mg *tlic 乙 oirtvollev CoAt 


^/dl "the rwodefs mission £ri*ti 乙 al 
A^d govgeous is -the viev/ 

I migivt be laz.y> bu 七 some-times it’s just ^v-az.y 

ttow rwufi.li 亡 ode I v/v-i*tc is jus 七 glue 

f[r\d i*t v/ouldh-t be so 

But 七 he Code aih-t doir>^ magi 乙 


Its jus*t rwov'mg values "Bivough 


I Aoy!{, rv\C3r> "to be vicious 
But it gets vcpcii-tious 
Po'm^ all "the "th'mgs 乙 oivbrollevs do 


A^d I v/isli I lidd 3 dime 
Fo\r cvciry single tirwC 




/V|odcl \/iew 

ftow we gorma deep si^c all -that glue 
/V|odcl \/iew Coh*tv"ollcv" 

Cor>*tvollcvs khow "tlie /Vlodcl 3hd \/icv/ vcv-y nvbima 七 ely 

They o^*tcy> use ha\rd£.od'm^ ^W\(M CBy\ be -fovcbod'mg (or 
vcusability 

Bu*t ho>w you ddr\ CoY\Y\tt{, ea 乙 h »v\odcl key 七 hat you select 
"to ar>y view p\ropc\r*ty 

A^d oh£.c you b'mdm^ 

I "tliihk you II be -Pmdmg less Code \y\ youv souv^c \xtt 

Veah I kr>ov/ I was dated by -the s-tu-f-f 七 heyV au-toma-ted 
a^d -the -tlimgs you get -for -Pvee 

A^d I "Uimk i*t bcavs vcpcatmg 
all "the Code you ^joy\{, be ^ccdmg 
wlic^ you hook i*t up 命私 

/V|odcl l/icw, CVCh hdhdlcs rwu|"tiplc Sclc^"tiohS 七 oo 
/V|odcl \/icw Coh*tvollcv* 

Model bc*t I ship rv»y applitatioh bc-forc you 
/V|odcl \/iew Cor\"tv"ollcv- 


DorVt just read! After all this is a Head First book... grab your iPod, hit this URL: 

http://www.headfirstlabs.com/books/hfdp/media.html 

Sit back and give it a listen. 
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mvc is patterns put together 


Cute song, but is that really 
supposed to teach me what Model- 
View-Controller is? I’ve tried 
learning MVC before and it made my 
brain hurt. 


No. Design Patterns are 
your key to the MVC. 

We were just trying to whet your appetite. 
Tell you what, after you finish reading this 
chapter, go back and listen to the song again 
一 you’ll have even more fun. 

It sounds like you’ve had a bad run in with 
MVC before? Most of us have. You’ve 
probably had other developers tell you it’s 
changed their lives and could possibly create 
world peace. It’s a powerful compound 
pattern, for sure, and while we can’t claim it 
will create world peace, it will save you hours 
of writing code once you know it. 



But first you have to learn it, right? Well, 
there’s going to be a big difference this time 
around because now you know patterns! 


That’s right, patterns are the key to MVC. 
Learning MVC from the top down is difficult; 
not many developers succeed. Here’s the 
secret to learning MVC: it’s just afew patterns 
put together. When you approach learning 
MVC by looking at the patterns, all of the 
sudden it starts to make sense. 


Let’s get started. This time around you’re 
going to nail MVC! 
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Meet the Model-View-Cowtroller 

Imagine you’re using your favorite MP3 player, like iTunes. You can use its interface to add 
new songs, manage playlists and rename tracks. The player takes care of maintaining a little 
database of all your songs along with their associated names and data. It also takes care of 
playing the songs and, as it does, the user interface is constantly updated with the current song 
title, the running time, and so on. 

Well, underneath it all sits the Model-View-Controller... 




1 Model tells the 
\ view the state has 
\ changed 

:—— - 

class Player { 
play(){} 
ripOU I 
burn(){} 

} 

/ 

The model don-taiw all -the state, 
data, and logit needed 

io mam-ta'm ar>d iplay ^ - 

Model 



Controller 


Controller asks / 
Player model to / 
begin playing / 
song 

controller 

manipulates 

the model 
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mvc up close 


Now let’s zoom into the 


A closer look... 

The MP3 Player description gives us a high level view of MVC, but it really doesn’t help you 
understand the nitty gritty of how the compound pattern works, how you’d build one yourself, or 
why it’s such a good thing. Let’s start by stepping through the relationships among the model, view 
and controller, and then we’ll take second look from the perspective of Design Patterns. 


CONTROLLER 

Takes user input and figures out 
what it means to the model. 

MODEL 


VIEW 

Gives you a presentation 
of the model. The view 
usually gets the state 
and data it needs to 
display directly from 
the model. 


The user did 
something 


Hcvcs tKc ext 叫 
•tVie middle. 



Controller 


Change your 


The model holds all 
the data, state and 
application logic. The 
model is oblivious to 
the view and controller, 
although it provides an 
interface to manipulate 
and retrieve its 
state and it can send 
notifications of state 
changes to observers. 


state 


③ Change your 
display 





TW»s \s i\\t 'Ascr 


④ 

I've changed! 


⑤ 

I need your state , 
information 


.~b, 

class Player 
play(){} 

ripOU 

burn(){} 


Model 


Hcvcs wodcl ； 
\i ^ar>dlcs all 
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① You're the user — you interact with the view. 

The view is your window to the model. When you do something to the view (like click 
the Play button) then the view tells the controller what you did. It’s the controllers 
job to handle that. 

② The controller asks the model to change its state. 

The controller takes your actions and interprets them. If you click on a button, it’s 
the controllers job to figure out what that means and how the model should be 
manipulated based on that action. 

③ The controller may also ask the view to change. 

_ When the controller receives an action from the view, it may need to tell the view 
to change as a result. For example, the controller could enable or disable certain 
buttons or menu items in the interface. 

④ The model notifies the view when its state has changed. 

When something changes in the model, based either on some action you took (like 
clicking a button) or some other internal change (like the next song in the playlist 
has started), the model notifies the view that its state has changed. 


⑤ The view asks the model for state. 

The view gets the state it displays directly from the model. For instance, when the 
model notifies the view that a new song has started playing, the view requests the 
song name from the model and displays it. The view might also ask the model for 
state as the result of the controller requesting some change in the view. 


Does the controller ever become 
an observer of the model? 

Sure. In some designs the controller 
registers with the model and is notified 
of changes. This can be the case when 
something in the model directly affects the 
user interface controls. For instance, certain 
states in the model may dictate that some 
interface items be enabled or disabled. If 
so, it is really controller’s job to ask the view 
to update its display accordingly. 


DumPc^uestiPiis 

All the controller does is take user 
input from the view and send it to the 
model, correct? Why have it at all if that 
is all it does? Why not just have the code 
in the view itself? In most cases isn’t the 
controller just calling a method on the 
model? 

The controller does more than 
just “send it to the model”，the controller is 
responsible for interpreting the input and 
manipulating the model based on that input. 
But your real question is probably “why can’t 
I just do that in the view code?” 


You could; however, you don’t want to 
for two reasons: First, you'll complicate 
your view code because it now has two 
responsibilities: managing the user interface 
and dealing with logic of how to control the 
model. Second, you’re tightly coupling your 
view to the model. If you want to reuse 
the view with another model, forget it. The 
controller separates the logic of control from 
the view and decouples the view from the 
model. By keeping the view and controller 
loosely coupled, you are building a more 
flexible and extensible design, one that can 
more easily accommodate change down the 
road. 
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the patterns in mvc 


Looking at MVC through 
patterws-colored glasses 

We’ve already told you the best path to learning the MVC is to see it for what it 
is: a set of patterns working together in the same design. 

Let’s start with the model. As you might have guessed the model uses 
Observer to keep the views and controllers updated on the latest state changes. 

The view and the controller, on the other hand, implement the Strategy Pattern. The controller 
is the behavior of the view, and it can be easily exchanged with another controller if you 
want different behavior. The view itself also uses a pattern internally to manage the windows, 
buttons and other components of the display: the Composite Pattern. 

Let’s take a closer look: 



Strategy 

The view and controller implement the classic Strategy Pattern: the 
view is an object that is configured with a strategy. The controller 
provides the strategy. The view is concerned only with the visual 
aspects of the application, and delegates to the controller for any 
decisions about the interface behavior. Using the Strategy Pattern also 
keeps the view decoupled from the model because it is the controller 
that is responsible for interacting with the model to carry out user 
requests. The view knows nothing about how this gets done. 



Each display component is a composite (like 
a window) or a leaf (like a button). When the 
controller tells the view to update, it only has 
to tell the top view component, and Composite 
takes care of the rest. 


keeps the model completely independent of 
the views and controllers. It allows us to use 
different views with the same model, or even 
use multiple views at once. 
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Strategy 


r\ 


The user did 
something 



The vie w 
del ^aie s io 
^onh-ollev 
^ndle ihe 
^ ^iions. 



Controller 


View 



The view only wovvies about fvesewia-tiow, -the donivolle*- wovvies 
about -tv-anslaiiwj usev inpu-t "to atiions on -the model- 


Controller 


丁 he ton-tvo'' elr ,s 

一 vt 、 如。 fe j etU , 
UOY-S W -to Wle 
•tv wsev attioftS. 


州 e dan swap in 

广。诎汴 beUi。*^ 

， view by 

七 he ^Oivtvollc^. 



TV^C v\cvi »s a to^os\it o-f 
$U| tom'por.C^-U (labels, 
Wtw, ⑶七”， 

tit! TV,cto ? level 
to^o^i tor^-ta'ms oi^tr 

oi^tr tor^crAs so 

or. wt»l 70 U yi io -t^c 
Ica-f v\odts. 
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mvc and the dj view 


Using MVC to control the beat... 

It’s your time to be the DJ. When you’re a DJ it’s all about the beat. You might start 
your mix with a slowed, downtempo groove at 95 beats per minute (BPM) and then 
bring the crowd up to a frenzied 140 BPM of trance techno. You’11 finish off your set 
with a mellow 80 BPM ambient mix. 



How are you going to do that? You have to control the beat and you’re going to build 
the tool to get you there. 


Meet the Java W View 

Let’s start with the view of the tool. The view allows you to create a 
driving drum beat and tune its beats per minute... 



A fulsinj bav sKoy/s -tKc beat m veal time. 


A display sKov/s -tKc 乙 uvreivt BPMs is 

auiomaiidally set v/Kc^cvcv- -tKc BP/V| 


The vie>w V>as W 

七 k ， 

■^e s-ta-te tVie model 

补 d 咖 〆 W ♦ — 


0 0 O Control 
DJ Control 
Enter BPM: 120 

( Set 




<< 




Pcdrcascs 

BPM W 

one bea-t ^ 
m'wwtc. 


l^v-cascs 

iKc BP/V| by 
or\t beat fev- 
m'mu-tc. 


You t^Y\ tt\{,cc a s^cti-fi^ BPM and dlitk 
iKc Set bu-tion -to set a s^>cti-fit bcais 
pev m'mu-tc, ov you 匕 an use tKc mtvease 
and decease buttons -fov -f 'mc 七 utVmg. 
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a -fc>w more y/ays {jo 乙 cnvbrol -fcKc PJ V'\ 


c>w ••• 


0 O 0 Control 




Stop 

Quit 


Set 




You ta« s-tart -t^e beat 

i/ k.dkmaW^ 005 ^ 


kitki 吋 W 

S-tav-t 眯 … 


\*tcw w *tV\c 


w po oW’ 伙 . 


Notidc S 七外 is 



disabled un-til you 
s-tavt tKc beat. 


V^ou use 

button "to sKu-t 
down -tKc beat 
geneva tior». 


No-tide S-tav-t is 
disabled a-f-tev- tKc 
beat Kas s-tavtcd- 




0 O O Control 


DJ Control 


Start | : 

Stop _ 

Quit Set 


<< 


.A 



The controller is m the middle... 

The controller sits between the view and 
model. It takes your input, like selecting “Start” 
from the DJ Control menu, and turns it into an 
action on the model to start the beat generation. 



TKc don-tv-ollcv takes i^u-t 
-fv-om -tKc user and -fijuves out 
Kow -to -tv-anslatc iKa-t mio 
requests Gt\ -the model. 


All usev actions avc 
"to tKc ^on-tv-ollcv*. 



Controller 


Let's wot forget about the model underneath it all. 

You can’t see the model, but you can hear it. The 
model sits underneath everything else, managing the 
beat and driving the speakers with MIDI. 



The BcatA^Iodcl is -tKc Kcav-t o( -tKc 
n irwplerwctrts "the logid 
io stairt ahd s-top ttc beat ； srt 
the beats y^y rwi^u-tc (BP/W), and 
JChCV-atc the souhd- 


r 

丁 he model also dllov/s us \,o 
ob-taih its duvvchi siaic 社 v— 
tKc gc-tBP/WO method. 
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the dj model, view and controller 

Putting the pieces together 


TKc bca-t is sc-t at 111 BPM and you 
yfould like io mdvease it to 12-0. 




Y^ou see 七 he bcatbav 

^ulsc every 1/2 - sedond- 


View 


0 O 0 View 


Current BPM: 120 


6 


0 O O Control 
DJ Control | 

Enter BPM: 

♦ Set ' 

(: << 


Clidk oh *tKc 

ihdv-casc beat 
bu-t"toh... 


View 


vcsults m tKc 
匕 oivbrollev* being invoked- 



B e „ the BPAI is IZO, ihe view yb 
a beat no iific 3 i ion evev - y j/ z se£ond 





TV^c to^vollcv asks 

-tKc model *to update 

its BPM by orvC. 


setBPMo 0 ff() I 

㈣ 一 



The view is updated 
tolZO BP/V|. 


t V,a^d. |UalU eetBPMO o« 

七 k model s*ta*tc. 
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building the pieces 

Okay, you know the model is responsible for maintaining all the data, state and any 
application logic. So what’s the BeatModel got in it? Its main job is managing the beat, 
so it has state that maintains the current beats per minute and lots of code that generates 
MIDI events to create the beat that we hear. It also exposes an interface that lets the 
controller manipulate the beat and lets the view and controller obtain the model’s state. 
Also, don’t forget that the model uses the Observer Pattern, so we also need some methods 
to let objects register as observers and send out notifications. 


Let's check out the ^eatModellnterface before looking at the 
implementation: 


TKcsc avc iKc mc-tKods 
■tKc dotvbrollev v/ill use "to 
divedi iKc model based ov\ 
user 


TV^csc mc-t^ods allow 
"the 

tor\*tv*ollcv- "to yt 
sUtc and to betome 
observers. 


public interface BeatModelInterface { 
void initialize () ; ^-- - 


void on(); 
void off(); 





void setBPM(int bpm); 

<e 


TW.s C 匕 

〜 TKcsc methods -tuvn tKc bcai 
gc^cva-tov on and 

This mciKod sets iKc bcais per 
m'mu-tc- it is tailed, beat 

-fv*c<\ucnty immcdia-tcly- 


int getBPM(); 


TKc ytBPMO method 

iKc tuv-veni BPMs, ov O i-f 

void registerObserver (BeatObserver o) ; jeneva-tov is o((. 

void removeObserver(BeatObserver o); 
void registerObserver(BPMObserver o); 
void removeObserver(BPMObserver o); 


7 


TVis should look 

•familiav, 
methods alloy/ 
objects -to reystev 
ds obsev-vevs *fov 

s-ta-tc ^a^cs. 



l/Ve’ve split "tKis iivto iv/o k'mds o( 
obsev-vevs ： observev-s -that v/ar»i b> be 
r»oii-ficd or\ cvcvy bcai, a^d obsewevs 
■tKa-t jus-t >war»-t "to be K»oti-ficd v/i-tK 
iKc bcais ytr m'mu-tc 
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the beat model 


Now let's have a look at the concrete ^eatModel class: 

⑷ e i 叶 lement tV<e BealAWellntev^ate. 


r TVis is heeded -for 
/V||D| todt. 


public class BeatModel implements BeatModelInterface, MetaEventListener { 


Sequencer sequencer; 

ArrayList beatObservers 
ArrayList bpmObservers 
int bpm = 90/ 

// other instance variables here 


new ArrayList(); 
new ArrayList(); 


public void initialize() 
setUpMidi(); 
buildTrackAndStart(); 

} 



TVis rwc-t^od docs 
srtuj? ov\ 

sets u^> bca 七 
-tracks fov us. 


丁 h sc<\ucndc\r is -the objed-t that khows Kow io 
jchcv-a-tc veal beats (tKa-t you tav\ Kcav.O. 

These Av-vayLis-b V^old -t>wo kmds of 
obscv-vcv-s (Bca-t and BPM observevs). 

TKc msiandc vaviable Kolds -fv-c^uc^y 
o( beats - by de-fault, BPM. 


public void on() { 

sequencer.start (); 冬 

setBPM(90); 


TKc oy»0 rwciKodi stavb ttc sc<\ucndcv- and 
sets 七 he BPMs -to dc-fault BP/Vj. 


public void off () { 
setBPM(O); 
sequencer.stop (); 

} 




/W o((0 sKuis ii down by srttihj BPMs -to 
0 and s-topp'mj -the sc^uendev-. 


tr 


{ 


public void setBPM(int bpm) 
this.bpm = bpm; 
sequencer.setTempoInBPM(getBPM() 
notifyBPMObservers() 

} 




public int getBPM() { 
return bpm; 

} 

void beatEvent() { 

notifyBeatObservers() 

} 


TKc se 七 BPM() rwrtKod is -tKc way *tKc don-tv*ollcr 
w«a^ifula-tes tKc beat- It docs iKrcc iK'mgs ： 

(I) Sets -tKc ms-ta^c vaviablc 

(Z) /\sks -tKc -to ^Kangc its BP/V|s. 

(V Noii-fics all BPM Observers tKat the BPM 
Kas ^Kanjcdi. 


The 5 e-tBP/V|() method jusl veW the b 卜 msla«te variable, 
mdida-tes iV>e duv-vent beals fev M^ie- 

、 The beatEvenlO “Ue BeatModel l^a«, is 

tailed by tV>e MlPl Code ^e»evev a nex beat stavts. This 'e 七 Wd 
no-t'^ies all Bea^bsewevs thai a 心 beat V>as jwt ottuvved. 


// Code to register and notify observers 
// Lots of MIDI code to handle the beat 




尺 eady-Wc & Code 

This model uses Java’s MIDI support to generate beats. You can check out the 
complete implementation of all the DJ classes in the Java source files available 
on the headfirstlabs.com site, or look at the code at the end of the chapter. 
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The View 


Now the fun starts; we get to hook up a view and visualize the BeatModel! 

The first thing to notice about the view is that we’ve implemented it so that it is displayed in two separate 
windows. One window contains the current BPM and the pulse; the other contains the interface 
controls. Why? We wanted to emphasize the difference between the interface that contains the view of 
the model and the rest of the interface that contains the set of user controls. Let’s take a closer look at 
the two parts of the view: 


PJ vicy/ 

displays two 

Jc 

Bca 七 Model … 


0 O 0 View 


Current BPM: 120 



七 v'icvj o-f 
model ^V-om 
v'icv/ *bV\c 




duvvcr»'t bc3"ts 
yty rw'mu-tc, -fv-orw 
i\\t BPMObscvvcv 


...and a puUmj w bca 七 
bav- w pulses \ y \ syndK 
WrtK ttc beat, dv-iven 
by Bca-tObscv-vcv 





嫌兑 - 

Our BeatModel makes no assumptions about the view. The model is implemented using the 
Observer Pattern, so it just notifies any view registered as an observer when its state changes. The 
view uses the model’s API to get access to the state. We’ve implemented one type of view, can you 
think of other views that could make use of the notifications and state in the BeatModel? 

A that is based oh veal-time beat- 


A 七 C 乂七 ual view 七 ha 七 displays a musid based Oh 七 he BPM (ambieivt, dov/hbeat, tcdhho, t{jtX 






the dj view 


Implementing the View 

The two parts of the view - the view of the model, and 
the view with the user interface controls - are displayed 
in two windows, but live together in one Java class. We’ll 
first show you just the code that creates the view of the 
model, which displays the current BPM and the beat bar. 
Then we’ll come back on the next page and show you just 
the code that creates the user interface controls, which 
displays the BPM text entry field, and the buttons. 



The code on these two 
pages is just an outline! 

-*-W • 

What we've done here is split ONE 
class into TWO, showing you one part 
of the view on this page, and the other 
part on the next page. All this code is 
really in ONE class - DJView.java. Its 
all listed at the back of the chapter. _ 


policy/ is an obsevvev -fov- botV) beats and BPM 

BeatObserver, BPMObserver { 


public class DJView implements ActionListener, 

BeatModelInterface model; 

Controller Inter face controller; 丁 ^ holds a -to bo-tK model and 


JFrame viewFrame; 、 
JPanel viewPanel; : 
BeatBar beatBar; 

JLabel bpmOutputLabel; 


"tKc doh-tvollcv. TKc doh-tvollcv- is o^ly used by -tKc 
n doh-tvol m-tcv--fadc, v/KidK v/cll ao ovcv m a set... 

〜 v/e tYtait a -Pew 

^ov -the display. 


public DJView(Controllerlnterface controller, 
this.controller = controller; 
this.model = model; 
model.registerObserver((BeatObserver)this) 
model.registerObserver((BPMObserver)this) 


public void createView() { 

// Create all Swing components here 

} 


BeatModelInterface model) { 

The dons-tvud-kov- gets a 
io i\\t don-tvollcv- and model, 
dnd >/c s-tovc to m 

■the vavidblcs- 




l/Vc also irejis-teir as a Bca-tObscv-vcv- ahd a 
BP/VIObscv-vcir o( -the model. 



public void updateBPM() { 

int bpm = model.getBPM() 
if (bpm == 0) { 

bpmOutput Label. setText (''offline"); 

} else { 

bpmOutputLabel. setText (''Current BPM: 

} 

} ，一 


The updaieBP/VlO method is called y/h £M a tiaie 
oCCu« rn the model. I/Vhe« that happens Vie 叩 date Ue 
display y/iU the BP/V). W e tan get Uis value 

b y 代 i 七 dWee.i\y 心咖七 he model. 


+ model.getBPM()), 


public void 
beatBar. 

} 


updateBeat() { 
setValue(100); 


Likewise, tKc upda-tcBca-tO meiKod is called 
when "the model s-ta\rts a hew beat iWh -tKa-t 
Kappchs ； wc wed 七。 pulse ouv w bcat bav. w Wc 
do -this by scttihj i*t io its value (lOO) 

IcUmj it Kahdlc -the ahi^a-tioh o( -the pulse. 
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Implementing the View, continued... 

Now, we’ll look at the code for the user interface controls part of the view. This view lets you control the 
model by telling the controller what to do, which in turn, tells the model what to do. Remember, this code 
is in the same class file as the other view code. 


public class DJView implements ActionListener, 
BeatModellnterface model; 

ControllerInterface controlle 
JLabel bpmLabel; 、 

JTextField bpmTextField; < 

JButton setBPMButton; 

JButton increaseBPMButton; 

JButton decreaseBPMButton; 

JMenuBar menuBar; 

JMenu menu; 

JMenuItem startMenuItem; 


BeatObserver, BPMObserver 


JMenuItem stopMenuItem; 4 

public void createControls() { 

// Create all Swing components 

} 

public void enableStopMenuItem() { 

stopMenuItem.setEnabled(true); 

} 

public void disableStopMenuItem() { 

stopMenuItem.setEnabled(false); 

} 

public void enableStartMenuItem() 

startMenuItem.setEnabled(true); 

} 


public void disableStartMenuItem() 

startMenuItem.setEnabled(false); 

} 






All "tKcsc methods allow -the s-tavt and 
stop i-tcrws Ih -the rwchu io be ehabled dhd 

f； sablc f d - uses 

these to dhahy the ihWafic. 


TVis rwciKod is called a bu-t-ton is dlitkcd- 


public void actionPerformed(ActionEvent event) { 
if (event.getSource() == setBPMButton) { 

int bpm = Integer.parselnt(bpmTextField.getText 
controller.setBPM(bpm); 

} else if (event.getSource() == increaseBPMButton) 
controller.increaseBPM(); 

} else if (event.getSource() == decreaseBPMButton) 
controller.decreaseBPM(); 


} 


0 )； 
{ 

{ 




|*f tKc Set bu 七七 cm is 
disked tKcn i*t is passed 
oy\ "to -tKc do^-tvollcv- along 
witK -tKc new 


Likewise, i-f -tKc m^v-casc 
or decease buttems avc 
disked, "this m-fovma-tion is 
passed on {jo "tKc 匕 cnvbrollev*- 


you are here ► 541 



the dj controller 


Now for the Controller 

It’s time to write the missing piece: the controller. Remember the controller is 
the strategy that we plug into the view to give it some smarts. 

Because we are implementing the Strategy Pattern, we need to start with an 
interface for any Strategy that might be plugged into the E)J View. We’re going 
to call it Controllerlnterface. 


public interface Controllerlnterface 
void start(); 
void stop(); 
void increaseBPM(); 
void decreaseBPM(); 
void setBPM(int bpm); 



Hcvc av-c all -the 
•^cihods -the view dah 
匕 a 11 oh "the doivtirollcv. 


TKcsc should look -familiav a-ftev- scc'mj iKc model's 

'micv-fadc. You tay\ stop dnd start tKc bcai 
<5 — ^enev-d-tion and BPM. TV>is m-tev-fade is 

<5~Bca-tModcl because you 

匕 an adjus-t -tKc BPMs wi-tK mdrease and dedvease- 



Design Puzzle 


You’ve seen that the view and controller together make use of the Strategy Pattern. Can you draw a 
class diagram of the two that represents this pattern? 
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And here's the implementation of the controller: 



TKc 乙 oivbrollev* irHpIcmeivts 

•tKc Co^-tvollcvl^-tcv-fa^c- 



public class BeatController implements ControllerInterface 
BeatModelInterface model; 

DJView view; 


public BeatController(BeatModelInterface 
this.model = model; 
view = new DJView(this, model); 
view.createView(); 
view.createControls(); 
view.disableStopMenuItem(); 
view.enableStartMenuItem(); 
model.initialize(); 


The fcon-tv-ollcv- is iKc dv-camy s-tu-f-f 
m *kKe middle o( MVC ovco 
Cookie, so i-t is -tKc object 七 ha 七 
gets to Kold on {jo view and 
model and glues it all -tojc-tKcv. 


TKc dontv-ollcv is passed 
model \y\ donsV^d-tov and 
dv-cates tKc view- 


} 


public void start() { 4 — 

model.on(); 

view•disableStartMenuItem() 
view.enableStopMenuItem(); 

} 


IA/V« e « YOU dhoose Sb 鈍心⑽ 4 必 

„od e l or, a«d tv> e « alt e « tv« e ^ 

SO tv>at tv>e 七 vt item is disabled a«d 

tV>e s-toip menw i'te» k enabled- 


public void stop() { 
model.off(); 

view.disableStopMenuItem(); 
view.enableStartMenuItem(); 

} 


public void increaseBPM() { 

int bpm = model.getBPM(); 
model.setBPM(bpm + 1); 

} 

public void decreaseBPM() { 

int bpm = model.getBPM(); 
model.setBPM(bpm - 1); 

} 


Likewise, when you dKoosc Stop -fy-om 
mtYWA, -the doh-tvollcir tuv-^s the model o-f-f 
ahd alters -the usev m-tev-fade so that 
the stop menu i-tem is disabled a^d iKc 
s^tairt rwChU item is enabled- 

l-f mdvease button is dlidkcd, iKc 

ton 七 vollev jets tKc duv-vent BPM 
•(Vorw 七 he i^odicl) adds oy\C ； 
scis a now BPM. 

K. 

£avne tK'mj V>cvc, only y/e sub-tvadt 
ov\t -fvorw duvve^'t BPM. 



public void setBPM(int 
model.setBPM(bpm); 

} 


bpm) 




I^OTB- tKc doh'tv'ollcv* is 

makihj -tKc nvtclliytrt 

dedisiohs -fov "the view. 

丁 he view jus-fc khov/s Kov/ 
"to "tuv-h menu i-terws ot\ 
ahd o ((； i-t doesn’t khow 

*tKc si 七 ud 七 ions in v/KidK i*t 
should disable -them. 


Pmally, i-f the usc\r mtev-fade is used "to 
set ah av-bitrav-y BP/VI, -tKc do^-tv-ollcv 
ihstvudis iKc model io set its BP/l/|. 
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Putting it all together:.. 

We’ve got everything we need: a model, a view, and a controller. 
Now it’s time to put them all together into a MVC! We’re going to 
see and hear how well they work together. 

All we need is a little code to get things started; it won’t take much: 


public class DJTestDrive { 

public static void main (String[] args) { 

BeatModellnterface model = new BeatModel() 



ControllerInterface controller = new BeatController(model); 


Fi 打七 扦沾 a ⑽ del.. 


} 


•■tKch dvca-tc a doh-tvollcv a^d 
pass i-t -tKc model- Rcmcmbcv, -tKc 
dotvbrollcv the view, so y/c 

do^-t Kavc -to do -tKat 


And wow fora test run.. 


I File Edit Window Help LetTheBassKick 


java DJTestDrive 




Run "this" 


•a^d you II see 七 his. 




Things to do 

o Start the beat generation with the Start menu item; 
notice the controller disables the item afterwards. 

o Use the text entry along with the increase and decrease 
buttons to change the BPM. Notice how the view 
display reflects the changes despite the fact that it has 
no logical link to the controls. 

o Notice how the beat bar always keeps up with the beat 
since it’s an observer of the model. 


0 O 0 View 

0 O 0 Control 


DJ Control 

Current BPM: 120 

Enter BPM: 


卜一 Set 

3 


<< ){ » 

■ 、 、 



o Put on your favorite song and see if you can beat match 
the beat by using the increase and decrease controls. 

o Stop the generator. Notice how the controller disables 
the Stop menu item and enables the Start menu item. 
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Exploring Strategy 

Let’s take the Strategy Pattern just a little further to get a better 
feel for how it is used in MVC. We’re going to see another 
friendly pattern pop up too _ a pattern you’ll often see hanging 
around the MVC trio: the Adapter Pattern. 

Think for a second about what the DJ View does: it displays 
a beat rate and a pulse. Does that sound like something else? 
How about a heartbeat? It just so happens we happen to have a 
heart monitor class; here’s the class diagram: 



HeartModel 

getHeartRate() 
registerBeatObserver() 
registerBPMObserver() 
II other heart methods 





3 ^ \ /W ludkily, i-U dcvclo\>cvs know about 

ttc Beat and BPM Obscv-vcv mW-fadcs) 





It certainly would be nice to reuse our current view with the HeartModel, but we need a controller that 
works with this model. Also, the interface of the HeatModel doesn’t match what the view expects 
because it has a getHeartRate() method rather than a getBPM(). How would you design a set of 
classes to allow the view to be reused with the new model? 
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Adapting the Model 

For starters, we’re going to need to adapt the HeartModel to a BeatModel. If we don’t，the view 
won’t be able to work with the model, because the view only knows how to getBPM。，and the 
equivalent heart model method is getHeartRate(). How are we going to do this? We’re going to 
use the Adapter Pattern, of course! It turns out that this is a common technique when working 
with the MVC: use an adapter to adapt a model to work with existing controllers and views. 

Here’s the code to adapt a HeartModel to a BeatModel: 

Y\ttd "to impIcw'Ctvt 
-tav-yk mtcv-fadc, m "tWis 
dasc, 

public class HeartAdapter implements BeatModellnterface { 

HeartModelInterface heart; 

public HeartAdapter(HeartModelInterface 
this.heart = heart; 

} 

public void initialize () {} ^ 

public void on () {} ^ We don'l know would do 

- 七 o a Kcavt, bu 七••七 sounds sdavy- S>o 

public void of f () { } ^ y/cll j'Ast as y\o o^s. 




Hcvc, y/c stove a vc-fcvcndc 
七 。 ttc Kcavt model. 



public int getBPM() { 

return heart.getHeartRate(); 



public void setBPM(int bpm) {} 



public void registerObserver(BeatObserver o) 
heart.registerObserver (o); 

} 

public void removeObserver(BeatObserver o) { 
heart.removeObserver(o); 

} 

public void registerObserver(BPMObserver o) 
heart.registerObserver(o); 

} 



iVb grtBPMO is tailed, v/cll jus-t 
■tvansla-tc it to a ytHcav-tRa'tcO dall 
or\ tKc model. 

Wc don-t y/ant to do Ais on a ^cav-t) 
Aga'm, let's leave i-t as a w no 


Hcv-c avc ouv obsevvev methods. 

1/Vc jus-t delegate tKcm to i\\t 
wa 打 cd heart modtl 


public void removeObserver(BPMObserver o) { 
heart.removeObserver(o); 

} 
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Now weYe ready for a HeartCowtrollcr 


With our HeartAdapter in hand we should be ready to create a controller and get the 
view running with the HeartModel. Talk about reuse! 




public class HeartController implements ControllerInterface { 
HeartModellnterface model; 

DJView view; 


public HeartController(HeartModellnterface model) 
this.model = model; 

view = new DJView(this, new HeartAdapter(model)) 
view.createView(); 
view.createControls(); 
view.disableStopMenuItem(); 
view.disableStartMenuItem(); 


public void start() {} 
public void stop () {} 
public void increaseBPM() {} 

public void decreaseBPM() {} 

public void setBPM(int bpm) {} 




TKc HcavtCon-tvollcv- ir^lcmcivks 
Uc Corrbrollcvlrrbffa 匕 C, jus 七 
like i\\t Bca-tCon-tvollcv did- 


Like bc-forc, "the doh*brollc\r 
dveates the view a^d jcis 
cvcvy-tKihj glued iogciKcv. 


TKcv'c is one avc passed a 

Hcav-tModcl ； 3 Bca*tModcl - 


wc need -to wvap -tKai 
model v/iiK adaftev- bc-fov-c 
wc hand i*t *to the view. 

Finally, the Hcav-tCo^-tv-ollcv- disables -the 
items as they av-c^i needed- 

ThevVs 。七 a let to do 
a-fic^r all, >/c tar^i really to^bro\ 


lil/# 


And thafs it! Now it's time for some test code... 


public class HeartTestDrive { 

public static void main (String[] args) { 

HeartModel heartModel = new HeartModel(); 

ControllerInterface model = new HeartController(heartModel); 

} } 4 



^11 y/c r>ccd to do is dveate 
i\st toyxbroWcy and pass it a 
V^cav-t rwonitov*- 
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Awd wow for a test row... 


File Edit Window Help CheckMyPulse 


java HeartTestDrive 


Ruh -tKis... 


•ahd you II see -tKis. 



Control 
DJ Control_ 

Enter BPM: 


Set 


<< 




Things to do 

^ Notice that the display works great with a heart! 

The beat bar looks just like a pulse. Because the 
HeartModel also supports BPM and Beat Observers we 
can get beat updates just like with the DJ beats. 

❾ As the heartbeat has natural variation, notice the 
display is updated with the new beats per minute. 

❺ Each time we get a BPM update the adapter is doing 
its job of translating getBPM() calls to getHeartRate() 
calls. 

^ The Start and Stop menu items are not enabled 
because the controller disabled them. 

❺ The other buttons still work but have no effect 

because the controller implements no ops for them. 
The view could be changed to support the disabling of 
these items. 


Q O Q View 

Current BPM: 68 
— 

卜 

/ 

Mice Kcal-tKy 
Kcav-t v-a-tc. 
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MVC awd the Web 


It wasn’t long after the Web was spun that developers started adapting the MVC to fit the 
browser/server model. The prevailing adaptation is known simply as “Model 2” and uses a 
combination of servlet andJSP technology to achieve the same separation of model, view and 
controller that we see in conventional GUIs. 

Let’s check out how Model 2 works: 



① You make an HTTP request, which is received by a servlet. 

Using your web browser you make an HTTP request. This typically involves 
sending along some form data, like your username and password. A servlet 
receives this form data and parses it. 

② The servlet acts as the controller. 

The servlet plays the role of the controller and processes your request, 
most likely making requests on the model (usually a database). The result 
of processing the request is usually bundled up in the form of a JavaBean. 

③ The controller forwards control to the view. 

The View is represented by a JSP. The JSP’s only job is to generate 
the page representing the view of model (④ which it obtains via the 
JavaBean) along with any controls needed for further actions. 

⑤ The view returns a page to the browser via HTTP. 

A page is returned to the browser, where it is displayed as the view. The 
user submits further requests, which are processed in the same fashion. 
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Model 2 is more than just 
a clean design. 


The benefits of the separation of the view, 
model and controller are pretty clear to 
you now. But you need to know the “rest 
of the story” with Model 2 — that it saved 
many web shops from sinking into chaos. 

How? Well, Model 2 not only provides 
a separation of components in terms of 
design, it also provides a separation in 
production responsibilities. Let 5 s face it, in the 
old days, anyone with access to your JSPs 
could get in and write any Java code they 
wanted, right? And that included a lot 
of people who didn’t know ajar file from 
ajar of peanut butter. The reality is that 


-fovmcv VOT COtA'cc 


most web producers know about content and 
HTML, not software. 


Luckily Model 2 came to the rescue. 

With Model 2 we can leave the developer 
jobs to the guys & girls who know their 
Servlets and let the web producers loose 
on simple Model 2 style JSPs where all 
the producers have access to is HTML 
and simple JavaBeans. 
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Model 2 : Wlwg from a cell phone 


You didn’t think we’d try to skip out without moving that 
great BeatModel over to the Web did you? Just think, you can 
control your entire DJ session through a web page on your 
cellular phone. So now you can get out of that DJ booth and 
get down in the crowd. What are you waiting for? Let’s write 
that code! 

The plan 

① Fix up the model. 

Well, actually, we don't have to fix the model, it’s fine just 
like it is! 

② Create a servlet controller 

We need a simple servlet that can receive our HTTP 
requests and perform a few operations on the model. All it 
needs to do is stop, start and change the beats per minute. 

③ Create a HTML view. 

Well create a simple view with a JSP. It's going to receive 
a JavaBean from the controller that will tell it everything 
it needs to display. The JSP will then generate an HTML 
interface. 



u foej: B 形 


Setting up your Servlet environment 


Showing you how to set up your servlet environment is a little bit off 
topic for a book on Design Patterns, at least if you don’t want the book 
to weigh more than you do! 


Fire up your web browser and head straight to 
http://jakarta.apache.org/tomcat/^or the Apache Jakarta Project’s 
Tomcat Servlet Container. You’ll find everything you need there to get 
you up and running. 

You’ll also want to check out Head First Servlets & JSP by Bryan 
Basham, Kathy Sierra and Bert Bates. 
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Step owe: the model 

Remember that in MVC, the model doesn’t know anything about the views or 
controllers. In other words it is totally decoupled. All it knows is that it may have 
observers it needs to notify. That’s the beauty of the Observer Pattern. It also 
provides an interface the views and controllers can use to get and set its state. 

Now all we need to do is adapt it to work in the web environment, but, given that 
it doesn’t depend on any outside classes, there is really no work to be done. We 
can use our BeatModel off the shelf without changes. So, let’s be productive and 
move on to step two! 


Step two: the controller servlet 


Remember, the servlet is going to act as our controller; it will receive Web browser 
input in a HTTP request and translate it into actions that can be applied to the 
model. 


Then, given the way the Web works, we need to return a view to the browser. To 
do this we’ll pass control to the view, which takes the form of aJSP We’ll get to 
that in step three. 

Here’s the outline of the servlet; on the next page, we’ll look at the full 
implementation. 



Wt extend t\ass 

so i\\ai y/c tar\ do scwlct kinds of 

like vctc'wc HTTP 'rc^ucs-ts. 


public class DJView extends HttpServlet { 

public void init() throws ServletException { 
BeatModel beatModel = new BeatModel(); 
beatModel.initialize(); 

getServletContext () . setAttribute (''beatModel", 

} 

// doPost method here 

public void doGet(HttpServletRequest request, 

HttpServletResponse response) 
throws IOException, ServletException 

{ 

// implementation here 



HevVs "Uie ini 七 wctKod ； 
•tWis is dalled ^ n \\ cy \ 
scwlct is -fiv-s-t treated. 


beatModel) ; -fiv-s-t Create a 



0 


BeatModel object.. 

•••ahd fladc a vc-fcvch^c *to 
it m the sc\rv|c-t ； s 七 
so iKat \i l s easily atusstd- 


Hcv*c s -fcKc do^ctO method- This is v/Kcvc "tKc v*cal v/o^k 
happhs. I/Ve ve got i*ts implcmch-taiioh oh iKc hcx-t pay. 
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Here’s the implementation of the doGetQ method from the page before: 


public void doGet(HttpServletRequest request, 

HttpServletResponse response) 
throws IOException, ServletException 

{ 

BeatModel beatModel = 



Fivs-t V/C JV-ab -tKc model -fv-om 
scwle 七 don-tex-t iA/c dan t 
mani^ula-te model Wrt^ou-t a 

Yt^Ccti\Ct io it 


(BeatModel)getServletContext() .getAttribute(''beatModel^); 


String bpm = request • getParameter ( 、 'bpm"); 

if (bpm == null) { 

bpm = beatModel. getBPM () + 

} 

String set = request • getParameter (''set"); 

if (set != null) { 

int bpmNumber = 90; 

bpmNumber = Integer.parselnt(bpm); 

beatModel.setBPM(bpmNumber); 

} 




yab ail "the http 

ton\n\By\d^/ ^3v3w'C'tc'rs... 


^ l-f >wc jet a set dommahd ； -tKc^ 
v/c jci iKc value o( -tKc set, 
ar>d icll -tKc modd- 


String decrease = request • getParameter (''decrease ’’）； 
if (decrease != null) { 

beatModel.setBPM(beatModel.getBPM() - 1); 

} 

String increase = request • getParameter (''increase"); 
if (increase != null) { 

beatModel.setBPM(beatModel.getBPM() + 1); 




} 

String on = request • getParameter (''on"); 
if (on != null) { 

beatModel.start(); 

} 

String off = request • getParameter (''off"); 
if (off != null) { 

beatModel.stop(); 


〆 


l*f we get oh ov o^-f domma^d ； we 
"tdl "tHc model to s*ta\rt ov- stop. 


Pmally, ouv job as a ^oh"tvo|lcv- 
is dohC- All wc heed "to do is 


} 


ask -the view -to -take ovcv- a^d 


request • setAttribute (''beatModel", beatModel); 



dveate HT/VJL view. 


RequestDispatcher dispatcher = 

request.getRequestDispatcher (' 、 /jsp/DJView. jsp’’> 
dispatcher.forward(request, response); 


rollow'mj the Model Z dc-fihiiioh, 
wc pass -the JSP a beah wi-tK -the 
model s-tatc m i-t. Im this case, v/e 


pass i 七 "the 3d*tual model ； sir>dc i"t 
Happens -to be a bean. 
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Now we need a view... 


All we need is a view and we’ve got our browser-based beat generator ready to go! 
In Model 2, the view is just aJSE All theJSP knows about is the bean it receives 
from the controller. In our case, that bean is just the model and theJSP is only 
going to use its BPM property to extract the current beats per minute. With that 
data in hand, it creates the view and also the user interface controls. 



our bcdn ； y/KidK 
tKc scvvlct passed us. 


<j sp : useBean id= 〃 beatModel" scope= 〃 request" class =,/ headfirst. combined.djview.BeatModel^ 

of "tKc HTML- 


<html> 

<head> 

<title>DJ View</title> 
</head> 

<body> 


Here we we 七 he «.odel bean 
y-b-ati ihe BP/VI p*-op e *-iy. 


<j sp : getProperty name= 〃 beatModel" property="BPM" /> 


<hl>DJ View</hl> 
Beats per minutes 
<br /> 

<hr> 

<br /> 


<form method="post" action="/djview/servlet/DJView"> 
BPM: 〈input type=text name= 〃 bpm 〃 

value="<j sp : getProperty name="beatModel 〃 
property="BPM" />"> 

&nbsp; 


Noy/ y/c 
jenevate tKc 
view, 

out 

•tKc duvvcivt 
beats fev 
rwmu-tc- 


<input type: 
<input type: 
<input type: 
<input type: 
<input type: 
</form> 

</body> 

</html> 


set’’ value="set’’><br /> 
decrease" value="<<"> 


’submit" name 
’submit" name 
'submit" name="increase" value="»"><b 
'submit" name="on" value="on"> 

’submit" name="off" value="off"><br /> 



Kcvc ; s -tKc doirbrol pavt 
of -tKc view. Have a 七 wt 
ty\bry (or cr»-tcv-'nr»5 a BPM 
alohj v/iiK mdvease/dedvease 

oy\/ o-f-f borttons. 


And Kcv-cs end 
HTML. 


MOTICB tKai jus-t like /V|\/C> m Model Z 
iKc view doesh-t al-tcv iKc model (-tKats -tKc 
dorrbrollev’s job); all rt does is use i*ts s-tatc/ 
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Putting Model 2 to the test... 


It’s time to start your web browser, hit the DJView Servlet and give 
the system a spin... 


TW,s '.stV> e 


如 A 加 ^ 

^ to^oUi ^ 

〜。 w use tV>e se > 

盯 TP t 。 咖 
砂 vkU 。 如、 W 

U yote 


DJ View 

C I I + ) ^htrp://localhost:8080/O * Google 


CD Address BookT Apple Amazon Yahoo! Local ▼ 
_ DJ View 

DJ View 

Beats per minutes = offline 


» 


BPM: 0 

GD GE) 


(S) 


(I) Usev dlidks the 

oy \ buttorv. 

(2-) Request »s SC ” 七 to 
tor\-bv*ollcv v\a HTTP. 


(V Beat is 
oy\ by\A set at 
dc-fault °[0 BPM. 


DJ View 

Beats per minutes = 9() 



BPM: 150 

® (>>) 

&) ’off 、 




(\) \/ic>N is vcW^cd 
via ttTTP a 灼 d 
d'is\>ldYcd. 

⑹ USCV- C^tcV-S ^CY/ 

BPM m 七作七 Acid. 


(i>) Uscv t\\tVs 
Set button- 


H) HTTP vc«\ucst 

•IS rnddc- 
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things 2 do with model 2 


(G) Corvbv-ollcv 

Aawys model 七 o 
\^0 BPMs 


(°l) \/'iC>w vdvns 

HTML 

d.uvvcr\t model 



0 O O DJ View 



Things to do 

A First, hit the web page; you’ll see the beats per minute at 0. Go ahead and 
click the M on” button. 

A Now you should see the beats per minute at the default setting: 90 BPM. You 
should also hear a beat on the machine the server is running on. 

❺ Enter a specific beat, say, 120, and click the M set w button. The page should 
refresh with a beats per minute of 120 (and you should hear the beat 
increase). 

❹ Now play with the increase/decrease buttons to adjust the beat up and down. 

❺ Think about how each step of the system works. The HTML interface makes 
a request to the servlet (the controller); the servlet parses the user input and 
then makes requests to the model. The servlet then passes control to the 
JSP (the view), which creates the HTML view that is returned and displayed. 
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Pesigvi Patterns awd Model 2 


After implementing the DJ Control for the Web using Model 2, you might be wondering where the patterns 
went. We have a view created in HTML from aJSP but the view is no longer a listener of the model. We have 
a controller that’s a servlet that receives HTTP requests，but are we still using the Strategy Pattern? And what 
about Composite? We have a view that is made from HTML and displayed in a web browser. Is that still the 
Composite Pattern? 

Model 2 is an adaptation of MVC to the Web 

Even though Model 2 doesn’t look exactly like “textbook” MVC, all the parts are still there; they’ve just been 
adapted to reflect the idiosyncrasies of the web browser model. Let’s take another look... 


Observer 

The view is no longer an observer 
of the model in the classic 
sense; that is, it doesn't register 
with the model to receive state 
change notifications. 

However, the view does receive 
the equivalent of notifications 
indirectly from the controller 
when the model has been 
changed. The controller even 
passes the view a bean that 
allows the view to retrieve the 
model’s state. 

If you think about the browser 
model, the view only needs an 
update of state information 
when an HTTP response is 
returned to the browser; 
notifications at any other time 
would be pointless. Only when 
a page is being created and 
returned does it make sense to 
create the view and incorporate 
the model’s state. 


Here's a new page 
to display 


r 



Web 

browser 

] 







User has done 
something 



JSP/HTML 

View 


bean 

Update your display, 
here's the new model. 
state 


Okay, I changed 
my state 



Controller 


TV,e Vie'N ^ m 

to ^o\\ev a 
.，一 … 加⑽ 
0 “ 叫脉 ㈣ * 
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Strategy 


In Model 2, the Strategy 
object is still the controller 
servlet; however, it's not 
directly composed with the 
view in the classic manner. 
That said, it is an object that 
implements behavior for the 
view, and we can swap it out 
for another controller if we 
want different behavior. 


Here's a new page 
to display 



Composite 

Like our Swing &UI, the 
view is ultimately made up 
of a nested set of graphical 
components. In this case, 
they are rendered by a 
web browser from an 
HTML description, however 
underneath there is an 
object system that most 
likely forms a composite. 


User has done 
something 



bean 

Update your display, 
here's the new model 
state 


JSP/HTML 

View 


Okay, I changed 
my state 



TKc 匕 o»vbrollev* still 
fvovidcs -tKc view 
bcKaviov*, cvch i-f it 
isy / 七 tom^ostd v/itK 
view using object 
dom^osi-tio»>. 



Change your 
state 
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It seems like you are really hand 
waving the fact that the Composite 
Pattern is really in MVC. Is it really 
there? 


Yes, Virginia, there really is a 
Composite Pattern in MVC. But, actually, 
this is a very good question. Today GUI 
packages, like Swing, have become so 
sophisticated that we hardly notice the 
internal structure and the use of composite 
in the building and update of the display. 

It’s even harder to see when we have Web 
browsers that can take markup language 
and convert it into a user interface. 

Back when MVC was first discovered, 
creating GUIs required a lot more manual 
intervention and the pattern was more 
obviously part of the MVC. 

Does the controller ever 
implement any application logic? 

No, the controller implements 
behavior for the view. It is the smarts 
that translates the actions from the view 
to actions on the model. The model 
takes those actions and implements the 
application logic to decide what to do in 
response to those actions. The controller 
might have to do a little work to determine 
what method calls to make on the model, 
but that’s not considered the “application 
logic.” The application logic is the code that 
manages and manipulates your data and it 
lives in your model. 


I’ve always found the word 
“model” hard to wrap my head around. 

I now get that it’s the guts of the 
application, but why was such a vague, 
hard-to-understand word used to 
describe this aspect of the MVC? 


felTcS 


lestiPns 


When MVC was named they needed 
a word that began with a “M” or otherwise 
they couldn’t have called it MVC. 

But seriously, we agree with you, everyone 
scratches their head and wonders what a 
model is. But then everyone comes to the 
realization that they can’t think of a better 
word either. 

You’ve talked a lot about the state 
of the model. Does this mean it has the 
State Pattern in it? 

No, we mean the general idea of 
state. But certainly some models do use the 
State Pattern to manage their internal states. 

I’ve seen descriptions of the MVC 
where the controller is described as a 
“mediator” between the view and the 
model. Is the controller implementing the 
Mediator Pattern? 

We haven’t covered the Mediator 
Pattern (although you’ll find a summary of 
the pattern in the appendix), so we won’t go 
into too much detail here, but the intent of 
the mediator is to encapsulate how objects 
interact and promote loose coupling by 
keeping two objects from referring to each 
other explicitly. So, to some degree, the 
controller can be seen as a mediator, since 
the view never sets state directly on the 
model, but rather always goes through the 
controller. Remember, however, that the 
view does have a reference to the model to 
access its state. If the controller were truly a 
mediator, the view would have to go through 
the controller to get the state of the model 
as well. 


Does the view always have to ask 
the model for its state? Couldn’t we use 
the push model and send the model’s 
state with the update notification? 

Yes, the model could certainly send 
its state with the notification, and in fact, if 
you look again at the JSP/HTML view, that’s 
exactly what we’re doing. We’re sending 
the entire model in a bean, which the view 
uses to access the state it needs using the 
bean properties. We could do something 
similar with the BeatModel by sending just 
the state that the view is interested in. If you 
remember the Observer Pattern chapter, 
however, you’ll also remember that there’s a 
couple of disadvantages to this. If you don’t 
go back and have a second look. 


If I have more than one view, do I 
always need more than one controller? 


Typically, you need one controller 
per view at runtime; however, the same 
controller class can easily manage many 
views. 


The view is not supposed to 
manipulate the model, however I noticed 
in your implementation that the view has 
full access to the methods that change 
the model’s state. Is this dangerous? 

You are correct; we gave the view 
full access to the model’s set of methods. 
We did this to keep things simple, but there 
may be circumstances where you want to 
give the view access to only part of your 
model’s API. There’s a great design pattern 
that allows you to adapt an interface to only 
provide a subset. Can you think of it? 
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Tools for your design Toolbox 

You could impress anyone with your design toolbox. 
Wow, look at all those principles, patterns and now, 
compound patterns! 


oo ? v ' w^ cs V 

工 ㈣ :： 

p c — 。” 如工二 s. 
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0 ^o\a^ss 
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赠 C 

a^d Model 2 - 3v*c 

- - 0 u 灼 d \>atbcv^s. 


Co. ? o^?a^- s ^ 

fC 。— 广 jitsi: 




BULLET POINTS 


The Model View Controller 
Pattern (MVC) is a compound 
pattern consisting of the 
Observer, Strategy and 
Composite patterns. 

The model makes use of the 
Observer Pattern so that it can 
keep observers updated yet 
stay decoupled from them. 

The controller is the strategy 
for the view. The view can use 
different implementations of 
the controller to get different 
behavior. 

The view uses the Composite 
Pattern to implement the 
user interface, which usually 
consists of nested components 
like panels, frames and 
buttons. 

These patterns work together 
to decouple the three players in 
the MVC model, which keeps 
designs clear and flexible. 

The Adapter Pattern can be 
used to adapt a new model to 
an existing view and controller. 

Model 2 is an adaptation of 
MVC for web applications. 

In Model 2, the controller is 
implemented as a servlet and 
JSP & HTML implement the 
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Exercise solutions 


: Sharpen your pencil 


The QuackCounter is a Quackable too. When we change Quackable to extend 
QuackObservable, we have to change every class that implements Quackable, 
including QuackCounter: 


^ ^ua^Cou^, '.s a ^kable, so 

L ^ fifuatkObscrvabU too. 


public class QuackCounter implements Quackable 
Quackable duck; 
static int numberOfQuacks; 


public QuackCounter(Quackable duck) 
this.duck = duck; 

} 

public void quack() { 
duck.quack(); 
numberOfQuacks++; 

} 


Hcvc ; s -the dudk 
^uadkCouhtcv is dcdov-a-t'mg. 
IVs -this dudk -that v-eally 

heeds -to Handle -the 

observable mciKods. 


public static int getQuacks() 
return numberOfQuacks; 

} 


^\\ Ji tw.s toAt is 


public void registerObserver(Observer observer) 
duck.registerObserver(observer); 

} ^ 


public void notifyObservers() 
duck.notifyObservers(); 

} 



Were a\rc ihc -two 

^uatk^bscv-vablc 
•^thods. Hoi\u that 
we just delate both 
^alls io -the dudk tha-t 

dcdovatih3. 
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sharpen solution 


Sharpen your pencil 


What if our Quackologist wants to observe an entire flock? What does that mean 
anyway? Think about it like this: if we observe a composite, then we’re observing 
everything in the composite. So, when you register with a flock, the flock composite 
makes sure you get registered with all its children, which may include other flocks. 


n pUk »s a fijuadlcaWe ， so ⑽如 
(vt，s a ^uatkObscwablc too. 

public class Flock implements Quackable { 

ArrayList ducks = new ArrayList (); ( 少 ^■ HcvVs 七 k $uadkablcs iha 七 

av-c m tKc Flodk. 

public void add(Quackable duck) { 
ducks.add(duck); 


public void quack() { 

Iterator iterator = ducks.iterator(); 
while (iterator.hasNext()) { 

Quackable duck = (Quackable)iterator.next(); 
duck.quack(); 

} 

} 




public void registerObserver(Observer observer) 
Iterator iterator = ducks.iterator(); 
while (iterator.hasNext()) { 

Quackable duck = (Quackable)iterator.next(); 
duck.registerObserver(observer); _ _ 〆 


public void notifyObservers() { } 


j 加 ftotk, 7 ow ^2 

ever/ 6?«atkable. ^ a 

d«dk ov anotViev 


Ea 乙 h Quddkdble docs i-ts ov/h hoti-fidatioh ； 
so Plodk docsh *t "to v/ovvy abou*t i*t. 
丁 his happchs wKch Flodk delegates 'uadkO 
io cadK ^uadkablc ih -the Flodk. 


別 t i*tc\ra*tc tKvoujK all iKc 
^uadkablcs ih iKc Flodk av\d 
delegate -the ta\\ io eadK 
^uadkablc- If the ^uadkable 

is dhO'tKcv Flo^k) rt will do 
七 he same- 
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专 Sharpen your pencil 


We’re still directly instantiating Geese by relying on concrete classes. Can you write 
an Abstract Factory for Geese? How should it handle creating "goose ducks?” 


Y^ou dould add a dvca-tc^ooscPudkO mc-tKod -to -tKc Dudk Fad-tov-ics. Or, you 

dould drca-tc a dom^lc-tcly scpavaic Fad-tov-y -fov dv-catmg -families of 



Design class 


You’ve seen that the View and Controller together make use of the Strategy Pattern. Can you draw a 
class diagram of the two that shows this pattern? 


TV view dclcga-tcs 
behavior io 

匕 oivbroll 饮 . TKc 
bchaviov i-fc 
dcle^aics is how io 
to^hro\ the model 
based Oh usev ihput 




Cor\-tvollcv*|r\tcv-fa^ c 
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do^-tv-ollcv-s 

TW»S is -tv»c stratcy/ 

•mtc 山“. 
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d\Ucrcv\i ^Oh-tvollcvs 

"to fvovidc di-P-Pcvch-t 

bc^aviovs -Pov -the view. 


you are here ► 563 



















ready-bake code: the dj application 


Here’s the complete implementation of the DJView. It shows all the 
MIDI code to generate the sound, and all the Swing components to 
create the view. You can also download this code at 
http://www.headfirstlabs.com. Have fun! 


package headfirst. combined, dj view; 

public class DJTestDrive { 

public static void main (String[] args) { 

BeatModellnterface model = new BeatModel(); 
Controllerlnterface controller = new BeatController(model); 

} 

} 


The Peat Model 


package headfirst. combined, dj view; 

public interface BeatModellnterface { 
void initialize(); 

void on(); 

void off(); 

void setBPM(int bpm); 

int getBPM(); 

void registerObserver(BeatObserver o); 
void removeObserver(BeatObserver o); 
void registerObserver(BPMObserver o); 
void removeObserver(BPMObserver o); 

} 
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package headfirst.combined.djview; 

import j avax.sound.midi.*; 
import java.util.*; 

public class BeatModel implements BeatModellnterface, 
Sequencer sequencer; 

ArrayList beatObservers = new ArrayList(); 
ArrayList bpmObservers = new ArrayList(); 
int bpm = 90; 

// other instance variables here 
Sequence sequence; 

Track track; 

public void initialize() { 

setUpMidi(); 
buildTrackAndStart(); 


public void on() { 

sequencer.start(); 
setBPM(90); 


public void off() { 
setBPM(O); 
sequencer.stop(); 

} 


public void setBPM(int bpm) { 
this.bpm = bpm; 

sequencer.setTempoInBPM(getBPM()); 
notifyBPMObservers(); 

} 

public int getBPM() { 
return bpm; 

} 

void beatEvent() { 

notifyBeatObservers(); 

} 


public void registerObserver(BeatObserver o) { 
beatObservers.add(o); 

} 

public void notifyBeatObservers() { 

for(int i = 0; i < beatObservers.size(); i++) 


MetaEventListener { 
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BeatObserver observer = (BeatObserver)beatObservers.get(i); 
observer.updateBeat(); 

} 

} 

public void registerObserver(BPMObserver o) { 
bpmObservers.add(o); 

} 

public void notifyBPMObservers() { 

for(int i = 0; i < bpmObservers.size (); i++) { 

BPMObserver observer = (BPMObserver)bpmObservers.get(i); 
observer.updateBPM(); 

} 

} 


public void removeObserver(BeatObserver o) { 
int i = beatObservers.indexOf(o); 
if (i >= 0) { 

beatObservers.remove(i); 

} 

} 


public void removeObserver(BPMObserver o) { 
int i = bpmObservers.indexOf(o); 
if (i >= 0) { 

bpmObservers.remove(i); 


public void meta(MetaMessage message) { 
if (message.getType() ==47) { 

beatEvent(); 
sequencer.start(); 
setBPM(getBPM()); 

} 

} 

public void setUpMidi() { 

try { 

sequencer = MidiSystem.getSequencer(); 
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sequencer.open(); 

sequencer.addMetaEventListener(this); 
sequence = new Sequence(Sequence.PPQ,4); 
track = sequence.createTrack(); 
sequencer.setTempoInBPM(getBPM()); 

} catch(Exception e) { 

e.printStackTrace(); 


public void buildTrackAndStart() { 
int[] trackList = {35, 0, 46, 0}; 

sequence.deleteTrack(null); 
track = sequence.createTrack(); 


makeTracks(trackList); 

track.add(makeEvent(192,9,1,0,4)); 

try { 

sequencer.setSequence(sequence); 
} catch(Exception e) { 
e.printStackTrace(); 


public void makeTracks(int[] list) { 

for (int i = 0; i < list.length; i++) { 

int key = list[i]; 

if (key != 0) { 

track.add(makeEvent(144,9,key, 100, i)); 
track.add(makeEvent(128,9,key, 100, i+1)); 



public MidiEvent makeEvent(int comd, int chan, int one, int two, int tick) { 
MidiEvent event = null; 
try { 

ShortMessage a = new ShortMessage(); 
a•setMessage(comd, chan, one, two); 
event = new MidiEvent(a, tick); 

} catch(Exception e) { 
e.printStackTrace(); 

} 

return event; 
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The View 

package headfirst.combined.djview; 




public interface BeatObserver { 
void updateBeat(); 


package headfirst. combined, dj view; 

public interface BPMObserver { 
void updateBPM(); 


package headfirst. combined, dj view; 

import java.awt.*; 
import java.awt.event.*; 
import j avax.swing.*; 

public class DJView implements ActionListener, BeatObserver, BPMObserver { 
BeatModellnterface model; 

ControllerInterface controller; 

JFrame viewFrame; 

JPanel viewPanel; 

BeatBar beatBar; 

JLabel bpmOutputLabel; 

JFrame controlFrame; 

JPanel controlPanel; 

JLabel bpmLabel; 

JTextField bpmTextField; 

JButton setBPMButton; 

JButton increaseBPMButton; 

JButton decreaseBPMButton; 

JMenuBar menuBar; 

JMenu menu; 

JMenuItem startMenuItem; 

JMenuItem stopMenuItem; 


public DJView(Controllerlnterface controller, BeatModellnterface model) { 
this.controller = controller; 
this.model = model; 

model.registerObserver((BeatObserver)this); 
model.registerObserver((BPMObserver)this); 

} 

public void createView() { 
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// Create all Swing components here 
viewPanel = new JPanel(new GridLayout(1, 2)); 
viewFrame = new JFrame (''View"); 

viewFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); 
viewFrame.setSize(new Dimension(100, 80)); 

bpmOutputLabel = new JLabel (''offline’'，SwingConstants . CENTER); 
beatBar = new BeatBar(); 
beatBar.setValue(0); 

JPanel bpmPanel = new JPanel(new GridLayout(2, 1)); 
bpmPanel.add(beatBar); 
bpmPanel.add(bpmOutputLabel); 
viewPanel.add(bpmPanel); 

viewFrame.getContentPane().add(viewPanel, BorderLayout.CENTER); 
viewFrame.pack(); 
viewFrame.setVisible(true); 


public void createControls() { 

// Create all Swing components here 

JFrame.setDefaultLookAndFeelDecorated(true); 

controlFrame = new JFrame (''Control"); 

controlFrame.setDefaultCloseOperation(JFrame.EXIT—ON—CLOSE); 
controlFrame.setSize(new Dimension(100, 80)); 

controlPanel = new JPanel(new GridLayout(1, 2)); 

menuBar = new JMenuBar(); 
menu = new JMenu (''DJ Control"); 
startMenuItem = new JMenuItem(' 、 Start"); 
menu.add(startMenuItem); 

startMenuItem.addActionListener(new ActionListener() { 

public void actionPerformed(ActionEvent event) { 
controller.start (); 

} 

})； 

stopMenuItem = new JMenuItem(''Stop"); 
menu.add(stopMenuItem); 

stopMenuItem.addActionListener(new ActionListener() { 

public void actionPerformed(ActionEvent event) { 
controller.stop(); 

/ /bpmOutputLabel. setText (''offline"); 

} 

})； 

JMenuItem exit = new JMenuItem(''Quit ’’）； 
exit.addActionListener(new ActionListener() { 

public void actionPerformed(ActionEvent event) { 

System.exit(0); 

} 

})； 
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menu.add(exit); 
menuBar.add(menu); 

controlFrame.setJMenuBar(menuBar); 


bpmTextField = new JTextField(2); 

bpmLabel = new JLabel (''Enter BPM:〃，SwingConstants • RIGHT); 
setBPMButton = new JButton ( 、 'Set 〃）； 
setBPMButton.setSize(new Dimension(10,40)); 
increaseBPMButton = new JButton ('、>>’'）； 
decreaseBPMButton = new JButton ('、<<"); 
setBPMButton.addActionListener(this); 
increaseBPMButton.addActionListener(this); 
decreaseBPMButton.addActionListener(this); 


JPanel buttonPanel = new JPanel(new GridLayout(1, 2)); 

buttonPanel.add(decreaseBPMButton); 
buttonPanel.add(increaseBPMButton); 


JPanel enterPanel = new JPanel(new GridLayout(1, 2)); 
enterPanel.add(bpmLabel); 
enterPanel.add(bpmTextField); 

JPanel insideControlPanel = new JPanel(new GridLayout(3, 1)); 

insideControlPanel.add(enterPanel); 

insideControlPanel.add(setBPMButton); 

insideControlPanel.add(buttonPanel); 

controlPanel.add(insideControlPanel); 


bpmLabel.setBorder(BorderFactory.createEmptyBorder(5,5,5,5)); 
bpmOutputLabel.setBorder(BorderFactory.createEmptyBorder(5,5,5,5)); 


controlFrame.getRootPane().setDefaultButton(setBPMButton); 
controlFrame.getContentPane().add(controlPanel, BorderLayout.CENTER); 

controlFrame.pack(); 
controlFrame.setVisible(true); 


public void enableStopMenuItem() { 

stopMenuItem.setEnabled(true); 

} 


public void disableStopMenuItem() { 

stopMenuItem.setEnabled(false); 
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} 

public void enableStartMenuItem() { 

startMenuItem.setEnabled(true); 

} 


public void disableStartMenuItem() { 

startMenuItem.setEnabled(false); 

} 

public void actionPerformed(ActionEvent event) { 
if (event.getSource() == setBPMButton) { 

int bpm = Integer.parselnt(bpmTextField.getText()); 
controller.setBPM(bpm); 

} else if (event.getSource() == increaseBPMButton) { 
controller.increaseBPM(); 

} else if (event.getSource() == decreaseBPMButton) { 
controller.decreaseBPM(); 

} 

} 


public void updateBPM() { 

int bpm = model.getBPM(); 
if (bpm == 0) { 

bpmOutputLabel. setText (''offline"); 

} else { 

bpmOutputLabel. setText (''Current BPM: '' + model. getBPM ()); 


public void updateBeat() { 

beatBar.setValue(100); 

} 


The Controller 

package headfirst.combined.djview; 


public interface ControllerInterface { 
void start(); 
void stop(); 
void increaseBPM(); 
void decreaseBPM(); 
void setBPM(int bpm); 


you are here 
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ready-bake code: controller 



package headfirst.combined.djview; 

public class BeatController implements ControllerInterface { 

BeatModelInterface model; 

DJView view; 

public BeatController(BeatModelInterface model) { 
this.model = model; 
view = new DJView(this, model); 
view.createView(); 
view.createControls(); 
view.disableStopMenuItem(); 
view.enableStartMenuItem(); 
model.initialize(); 


public void start() { 
model.on(); 

view.disableStartMenuItem(); 
view.enableStopMenuItem(); 


public void stop() { 
model.off(); 

view.disableStopMenuItem(); 
view.enableStartMenuItem(); 


public void increaseBPM() { 

int bpm = model.getBPM(); 
model.setBPM(bpm + 1); 


public void decreaseBPM() { 

int bpm = model.getBPM(); 
model.setBPM(bpm - 1); 


public void setBPM(int bpm) { 
model.setBPM(bpm); 


572 


Chapter 12 



compound patterns 


The Heart Model 


package headfirst.combined.djview; 

public class HeartTestDrive { 

public static void main (String[] args) { 

HeartModel heartModel = new HeartModel(); 

ControllerInterface model = new HeartController(heartModel); 


package headfirst. combined, dj view; 
public interface HeartModelInterface { 
int getHeartRate(); 

void registerObserver(BeatObserver o); 
void removeObserver(BeatObserver o); 
void registerObserver(BPMObserver o); 
void removeObserver(BPMObserver o); 


package headfirst. combined, dj view; 
import java.util.*; 


public class HeartModel implements HeartModelInterface. Runnable { 
ArrayList beatObservers = new ArrayList(); 

ArrayList bpmObservers = new ArrayList(); 
int time = 1000; 
int bpm = 90; 

Random random = new Random(System.currentTimeMillis()); 

Thread thread; 

public HeartModel() { 

thread = new Thread(this); 
thread.start(); 


public void run() { 

int lastrate = -1; 

for(;;) { 

int change = random.nextInt(10); 
if (random.nextlnt(2) == 0) { 
change = 0 - change; 

} 

int rate = 60000/(time + change); 
if (rate < 120 && rate > 50) { 
time += change; 
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notifyBeatObservers(); 
if (rate != lastrate) { 
lastrate = rate; 
notifyBPMObservers() 


try { 

Thread.sleep(time); 

} catch (Exception e) {} 

} 

} 

public int getHeartRate() { 

return 60000/time; 

} 

public void registerObserver(BeatObserver o) { 
beatObservers.add(o); 

} 

public void removeObserver(BeatObserver o) { 
int i = beatObservers.indexOf(o); 
if (i >= 0) { 

beatObservers.remove(i); 

} 

} 

public void notifyBeatObservers() { 

for (int i = 0; i < beatObservers.size(); i++) { 

BeatObserver observer = (BeatObserver)beatObservers.get(i); 
observer.updateBeat(); 

} 

} 

public void registerObserver(BPMObserver o) { 
bpmObservers.add(o); 

} 

public void removeObserver(BPMObserver o) { 
int i = bpmObservers.indexOf(o); 
if (i >= 0) { 

bpmObservers.remove(i); 

} 

} 

public void notifyBPMObservers() { 

for(int i = 0; i < bpmObservers.size (); i++) { 

BPMObserver observer = (BPMObserver)bpmObservers.get(i); 
observer.updateBPM(); 

} 

} 
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The Heart Adapter 


package headfirst.combined.djview; 

public class HeartAdapter implements BeatModellnterface { 

HeartModelInterface heart; 

public HeartAdapter(HeartModelInterface heart) { 
this.heart = heart; 

} 

public void initialize () {} 

public void on() {} 

public void off () {} 

public int getBPM() { 

return heart.getHeartRate(); 

} 

public void setBPM(int bpm) {} 

public void registerObserver(BeatObserver o) { 
heart.registerObserver(o); 

} 

public void removeObserver(BeatObserver o) { 
heart.removeObserver(o); 

} 

public void registerObserver(BPMObserver o) { 
heart.registerObserver(o); 

} 

public void removeObserver(BPMObserver o) { 
heart.removeObserver(o); 

} 


you are here 
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ready-bake code: heart beat controller 

The Controller 



package headfirst.combined.djview; 

public class HeartController implements ControllerInterface { 
HeartModelInterface model; 

DJView view; 

public HeartController(HeartModellnterface model) { 
this.model = model; 

view = new DJView(this, new HeartAdapter(model)); 
view.createView(); 
view.createControls(); 
view.disableStopMenuItem(); 
view.disableStartMenuItem(); 


public void start () {} 
public void stop () {} 
public void increaseBPM() {} 

public void decreaseBPM() {} 

public void setBPM(int bpm) {} 
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^Patterns in the 
卞 Real World 





Ahhhh, now you’re ready for a bright new world filled with 
Design Patterns. But, before you go opening all those new doors of opportunity, we 
need to cover a few details that you’ll encounter out in the real world - that’s right, things get 
a little more complex than they are here in Objectville. Come along, we’ve got a nice guide to 
help you through the transition on the next page... 


this is a new chapter 
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what you’ll learn from the guide 
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design Pattern defined 

We bet you’ve got a pretty good idea of what a pattern is after reading this book. But 
we’ve never really given a definition for a Design Pattern. Well, you might be a bit 
surprised by the definition that is in common use: 


A Pattern is a solution to a problem in a context. 


That’s not the most revealing definition is it? But don’t worry, we’re going to step 
through each of these parts, context, problem and solution: 


ha—e: > ^ avc a 


The context is the situation in which the pattern applies. This 
should be a recurring situation. 

The problem refers to the goal you are trying to achieve in this 
context, but it also refers to any constraints that occur in the 
context. 

The solution is what you’re after: a general design that anyone 
can apply which resolves the goal and set of constraints. 


Y^ou Y\ttd to s-tcp 
■tWough -tlic objects 

- v/rthou-t exposing 

■the tollcdtio^s 
irwplcrwCr>"ta*tior>. 

ihioa 

tlass. 


This is one of those definitions that takes a while to sink in, but take it one step at a 
time. Here’s a little mnemonic you can repeat to yourself to remember it: 

W |-P you -P'md you\rscl-f m a 乙。矜七以七 s pvoblcrw -that has a goal 
七 is a-f-felted by a sc-t o( 乙 or\s"brai»vts, you 乙 ar> apply 

a design -that vcsolvcs -the goal a^d ^ohs-tra'mts leads -to a 
solution.’’ 


Now, this seems like a lot of work just to figure out what a Design Pattern is. After all, 
you already know that a Design Pattern gives you a solution to a common recurring 
design problem. What is all this formality getting you? Well, you’re going to see that 
by having a formal way of describing patterns we can create a catalog of patterns, 
which has all kinds of benefits. 


you are here 


579 




design pattern defined 


I’ve been thinking 
about the three-part 
definition, and I don’t think 
it defines a pattern at all. 



You might be right; let’s think about this a bit... We need a problem，a 
solution and a context: 


Problem: How do I get to work on time? 
Context: I’ve locked my keys in the car. 


Solution: Break the window, get in the car, start 
the engine and drive to work. 


We have all the components of the definition: we have a problem, 
which includes the goal of getting to work, and the constraints of time, 
distance and probably some other factors. We also have a context in 
which the keys to the car are inaccessible. And we have a solution that 
gets us to the keys and resolves both the time and distance constraints. 
We must have a pattern now! Right? 


We followed the Design Pattern definition and defined a problem, a context, and a solution (which 
works!). Is this a pattern? If not, how did it fail? Could we fail the same way when defining an 00 
Design Pattern? 
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Looking more closely at the 
Pesigw Patterw definition 

Our example does seem to match the Design 
Pattern definition, but it isn’t a true pattern. Why? 
For starters, we know that a pattern needs to apply 
to a recurring problem. While an absent-minded 
person might lock his keys in the car often, breaking 
the car window doesn’t qualify as a solution that 
can be applied over and over (or at least isn’t likely 
to if we balance the goal with another constraint: 
cost). 

It also fails in a couple of other ways: first, it isn’t 
easy to take this description, hand it to someone 
and have him apply it to his own unique problem. 
Second, we’ve violated an important but simple 
aspect of a pattern: we haven’t even given it a 
name! Without a name, the pattern doesn’t 
become part of a vocabulary that can be shared 
with other developers. 

Luckily, patterns are not described and documented 
as a simple problem, context and solution; we 
have much better ways of describing patterns and 
collecting them together into patterns catalogs. 


Next time someone tells you 
a pattern is a solution to a problem 
in a context, just nod and smile. You 
know what they mean, even if it isn’t a 
definition sufficient to describe what 
a Design Pattern really is. 



Am I going to see pattern 
descriptions that are stated as a problem, 
a context and a solution? 

Pattern descriptions, which you’ll 
typically find in pattern catalogs, are usually 
a bit more revealing than that. We’re going 
to look at pattern catalogs in detail in just 
a minute; they describe a lot more about a 
pattern’s intent and motivation and where it 
might apply, along with the solution design 
and the consequences (good and bad) of 
using it. 


Is it okay to slightly alter a 
pattern’s structure to fit my design? Or 
am I going to have to go by the strict 
definition? 

Of course you can alter it. Like 
design principles, patterns are not meant 
to be laws or rules; they are guidelines that 
you can alter to fit your needs. As you’ve 
seen, a lot of real-world examples don’t fit 
the classic pattern designs. 

However, when you adapt patterns, it 
never hurts to document how your pattern 
differs from the classic design - that way, 
other developers can quickly recognize the 
patterns you’re using and any differences 
between your pattern and the classic 
pattern. 


Where can I get a patterns 
catalog? 

The first and most definitive 
patterns catalog is Design Patterns: 
Elements of Reusable Object-Oriented 
Software, by Gamma, Helm, Johnson & 
Vlissides (Addison Wesley). This catalog 
lays out 23 fundamental patterns. We’ll talk 
a little more about this book in a few pages. 

Many other patterns catalogs are starting to 
be published in various domain areas such 
as enterprise software, concurrent systems 
and business systems. 


you are here ► 
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U Gee ): 娜 - 

May the force be with you 

The Design Pattern 
definition tells us that 
the problem consists of a 
goa/and a set of constraints. 

Patterns gurus have a term 
for these: they call them 
forces. Why? Well, we're sure 
they have their own reasons, but if 
you remember the movie, the force 
“shapes and controls the Universe." 

Likewise, the forces in the pattern 
definition shape and control the solution. 

Only when a solution balances both sides of 
the force (the light side: your goal, and the dark 
side: the constraints) do we have a useful pattern. 

This “force” terminology can be quite confusing 
when you first see it in pattern discussions, but 
just remember that there are two sides of the force 
(goals and constraints) and that they need to be 
balanced or resolved to create a pattern solution. Don’t 
let the lingo get in your way and may the force be with you! 
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Frank: Fill us in, Jim. I’ve just been learning patterns by reading a 
few articles here and there. 

Jim ： Sure, each pattern catalog takes a set of patterns and describes 
each in detail along with its relationship to the other patterns. 

Joe ： Are you saying there is more than one patterns catalog? 

Jim ： Of course; there are catalogs for fundamental Design Patterns 
and there are also catalogs on domain specific patterns, like EJB 
patterns. 

Frank: Which catalog are you looking at? 

Jim: This is the classic GoF catalog; it contains 23 fundamental 
Design Patterns. 

Frank ： GoF? 

Jim ： Right, that stands for the Gang of Four. The Gang of Four are 
the guys that put together the first patterns catalog. 

Joe ： What’s in the catalog? 

Jim ： There is a set of related patterns. For each pattern there is a 
description that follows a template and spells out a lot of details of the 
pattern. For instance, each pattern has a name. 
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Frank: Wow, that’s earth-shattering — a name! Imagine that. 

Jim ： Hold on Frank; actually, the name is really important. When we have a name 
for a pattern, it gives us a way to talk about the pattern; you know, that whole shared 
vocabulary thing. 

Frank: Okay, okay. I was just kidding. Go on, what else is there? 

Jim ： Well, like I was saying, every pattern follows a template. For each pattern we have 
a name and a few sections that tell us more about the pattern. For instance, there is an 
Intent section that describes what the pattern is, kind of like a definition. Then there are 
Motivation and Applicability sections that describe when and where the pattern might be 
used. 

Joe ： What about the design itself? 

Jim ： There are several sections that describe the class design along with all the classes 
that make it up and what their roles are. There is also a section that describes how to 
implement the pattern and often sample code to show you how. 

Frank: It sounds like they’ve thought of everything. 

Jim ： There’s more. There are also examples of where the pattern has been used in real 
systems as well as what I think is one of the most useful sections: how the pattern relates 
to other patterns. 

Frank: Oh, you mean they tell you things like how state and strategy differ? 

Jim ： Exactly! 

Joe ： So Jim, how are you actually using the catalog? When you have a problem, do you 
go fishing in the catalog for a solution? 

Jim ： I try to get familiar with all the patterns and their relationships first. Then, when I 
need a pattern, I have some idea of what it is. I go back and look at the Motivation and 
Applicability sections to make sure I’ve got it right. There is also another really important 
section: Consequences. I review that to make sure there won’t be some unintended effect 
on my design. 

Frank: That makes sense. So once you know the pattern is right, how do you approach 
working it into your design and implementing it? 

Jim ： That’s where the class diagram comes in. I first read over the Structure section to 
review the diagram and then over the Participants section to make sure I understand each 
classes’ role. From there I work it into my design, making any alterations I need to make 
it fit. Then I review the Implementation and Sample code sections to make sure I know 
about any good implementation techniques or gotchas I might encounter. 

Joe ： I can see how a catalog is really going to accelerate my use of patterns! 

Frank: Totally. Jim, can you walk us through a pattern description? 
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discovering your own patterns 


DumPc^iiestiPiis 


Is it possible to create your own Design 
Patterns? Oris that something you have to be a 
“patterns guru” to do? 


First, remember that patterns are discovered, 
not created. So, anyone can discover a Design Pattern 
and then author its description; however, it's not easy 
and doesn’t happen quickly, nor often. Being a “patterns 
writer” takes commitment. 

You should first think about why you’d want to - the 
majority of people don’t author patterns; they just use 
them. However, you might work in a specialized domain 
for which you think new patterns would be helpful, or 
you might have come across a solution to what you 
think is a recurring problem, or you may just want to get 
involved in the patterns community and contribute to the 
growing body of work. 

I’m game; how do I get started? 

Like any discipline, the more you know the 
better. Studying existing patterns, what they do and 
how they relate to other patterns is crucial. Not only 
does it make you familiar with how patterns are crafted, 
it prevents you from reinventing the wheel. From there 
you’ll want to start writing your patterns on paper, so you 
can communicate them to other developers; we’re going 
to talk more about how to communicate your patterns in 
a bit. If you’re really interested, you’ll want to read the 
section that follows these Q&As. 


How do I know when I really have a pattern? 

That’s a very good question: you don’t have a 
pattern until others have used it and found it to work. 

In general, you don’t have a pattern until it passes the 
“Rule of Three.” This rule states that a pattern can be 
called a pattern only if it has been applied in a real-world 
solution at least three times. 
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So you wanna be a design Patterns writer 


Do your homework. You need to be well versed in the 
existing patterns before you can create a new one. Most patterns 
that appear to be new, are, in fact, just variants of existing 
patterns. By studying patterns, you become better at recognizing 
them, and you learn to relate them to other patterns. 


Take time to reflect, evaluate. Your experience — the 
problems you’ve encountered, and the solutions you’ve used — are 
where ideas for patterns are born. So take some time to reflect 
on your experiences and comb them for novel designs that recur. 
Remember that most designs are variations on existing patterns 
and not new patterns. And when you do find what looks like a 
new pattern, its applicability may be too narrow to qualify as a 
real pattern. 


Get your ideas down on paper in a way others can 
understand. Locating new patterns isn’t of much use if others 
can’t make use of your find; you need to document your pattern 
candidates so that others can read, understand, and apply them 
to their own solution and then supply you with feedback. Luckily, 
you don’t need to invent your own method of documenting your 
patterns. As you’ve already seen with the GoF template, a lot of 
thought has already gone into how to describe patterns and their 
characteristics. 


Have others try your patterns; then refine and refine 
some more. Don’t expect to get your pattern right the first 
time. Think of your pattern as a work in progress that will 
improve over time. Have other developers review your candidate 
pattern, try it out, and give you feedback. Incorporate that 
feedback into your description and try again. Your description 
will never be perfect, but at some point it should be solid enough 
that other developers can read and understand it. 


Don’t forget the rule of three. Remember, unless your 
pattern has been successfully applied in three real-world 
solutions, it can’t qualify as a pattern. That’s another good 
reason to get your pattern into the hands of others so they can 
try it, give feedback, and allow you to converge on a working 
pattern. 



Use oy>c o-f i\\t …七叫 
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who does what? 


卡 


十 


♦ 




Match each pattern with its description: 

Pattern 


Decprqtpr 


Templctt© M©tk>c[ 

Composite 
Singletpn 
Abstract Factory 
Cpinmancl 


Description 



Wraps an object and provides a dlSerent 
Interface t? ft. 

Subclasses decide tP implement steps 
In an sd^Qrithm. 

Subclasses decide wtloli concrete classes fo 
creftte- 

Ensures one Eind only object is cre£tt©cl. 

Encapsulates IntercJiEin^eakle ketaVlprs and 

uses deleg£ttiQn to decide wtlcji one fo use. 

Clients treett collections of objects and 
Individual objects uniformly. 

Encapsulates st£tt©-t>asecl ketaVIprs and uses 
delegsttjon tP sWitcJi between ketaViors- 

rr^Vldes a wa/1? traVerse a collection 
objects Without exposing its ImplemeritEttiPn. 

Simplifies the Interface a set classes. 

Wraps £in object t? provide new ketaVIpr. 

Allows a client tP cre£tte ?amllies objects 
Without specifying their concrete classes. 

All^Ws objects IP ke np^^ied wten st£tt© 
chm^es. 

Wraps an object t? control access t? ft. 
Encapsulates a request as £in object. 
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Organizing design Patterns 

As the number of discovered Design Patterns grows, it makes sense to partition them into classifications so 
that we can organize them, narrow our searches to a subset of all Design Patterns, and make comparisons 
within a group of patterns. 

In most catalogs you’ll find patterns grouped into one of a few classification schemes. The most well-known 
scheme was used by the first pattern catalog and partitions patterns into three distinct categories based on 
their purposes: Creational, Behavioral and Structural. 


7 Sharpen your pencil 



[stQtTj 


Read each category description and see 
if you can corral these patterns into their 
correct categories. This is a toughy! But 
give it your best shot and then check out 
the answers on the next page. 


[Command) - 1 roxy lr~ - 

j Facade J 


Creational patterns involve 
object instantiation and all 
provide a way to decouple a client 
from the objects it needs to 
instantiate. 



UtM ^ 如 sc ? a . 




m or\t 


^ 从 。 se ta 


Any pattern that is a Behavioral 
Pattern is concerned with how 
classes and objects interact and 
distribute responsibility. 



Structural patterns let you 

compose classes or objects 
into larger structures. 
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pattern categories 


Solution ： Pattern Categories 

Here’s the grouping of patterns into categories. You probably found the exercise difficult, 
because many of the patterns seem like they could fit into more than one category. Don’t worry, 
everyone has trouble figuring out the right categories for the patterns. 


Creational patterns involve 
object instantiation and all 
provide a way to decouple a client 
from the objects it needs to 
instantiate. 


Any pattern that is a Behavioral 
Pattern is concerned with how 
classes and objects interact and 
distribute responsibility. 



Structural patterns let you 

compose classes or objects 
into larger structures. 


Wcvc 50-t a pa-t-bc^^ 
• ^vcy) -tKa-t you havc^-t 

八 a yet Voull -f'md 
OVCVVlCVi 七 he 

rn i\\t a^c^d'iy.. 
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Patterns are often classified by a second attribute: whether or not 
the pattern deals with classes or objects: 


Class patterns describe how relationships between 
classes are defined via inheritance. Relationships in 
class patterns are established at compile time. 


Object patterns describe 
relationships between 
objects and are primarily 
defined by composition. 



Are these the only classification 
schemes? 

No, other schemes have been 
proposed. Some other schemes start 
with the three categories and then add 
subcategories, like “Decoupling Patterns •” 
You’ll want to be familiar with the most 
common schemes for organizing patterns, 
but also feel free to create your own, if it 
helps you to understand the patterns better. 

Does organizing patterns into 
categories really help you remember 
them? 


DumPc^uestiPiis 

It certainly gives you a framework 
for the sake of comparison. But many 
people are confused by the creational, 
structural and behavioral categories; often 
a pattern seems to fit into more than one 
category. The most important thing is to 
know the patterns and the relationships 
among them. When categories help, use 
them! 

Why is the Decorator Pattern in 
the structural category? I would have 
thought of that as a behavioral pattern; 
after all it adds behavior! 


Yes, lots of developers say that! 
Here’s the thinking behind the Gang of Four 
classification: structural patterns describe 
how classes and objects are composed to 
create new structures or new functionality. 
The Decorator Pattern allows you to 
compose objects by wrapping one object 
with another to provide new functionality. 

So the focus is on how you compose the 
objects dynamically to gain functionality, 
rather than on the communication and 
interconnection between objects, which is 
the purpose of behavioral patterns. But 
remember, the intent of these patterns 
is different, and that’s often the key to 
understanding which category a pattern 
belongs to. 
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pattern categories 



Master and Student" 

Master: Grasshopper, you look troubled. 

Student: Yes, I’ve just learned about 
pattern classification and I’m confused. 

Master: Grasshopper, continue... 


Student: After learning much about patterns, I’ve 
just been told that each pattern fits into one of three 
classifications: structural，behavioral or creational. Why 
do we need these classifications? 


Master: Grasshopper, whenever we have a large 
collection of anything, we naturally find categories to fit 
those things into. It helps us to think of the items at a 
more abstract level. 


Student: Master; can you give me an example? 

Master: Of course. Take automobiles; there are many 
different models of automobiles and we naturally put 
them into categories like economy cars, sports cars, 
SUVs，trucks and luxury car categories. 

Master: Grasshopper, you look shocked, does this not 
make sense? 


Student: Master, it makes a lot of sense, but I am 
shocked you know so much about cars! 

Master: Grasshopper, I can’t relate everything to lotus 
flowers or rice bowls. Now, may I continue? 

Student: Yes, yes, I’m sorry, please continue. 

Master: Once you have classifications or categories 
you can easily talk about the different groupings: “If 
you’re doing the mountain drive from Silicon Valley to 
Santa Cruz, a sports car with good handling is the best 
option.” Or, “With the worsening oil situation you really 
want to buy a economy car, they're more fuel-efficient.” 

Student: So by having categories we can talk about a 
set of patterns as a group. We might know we need a 
creational pattern, without knowing exactly which one, 
but we can still talk about creational patterns. 

Master: Yes, and it also gives us a way to compare a 
member to the rest of the category, for example, “the 
Mini really is the most stylish compact car around”，or 
to narrow our search, 7 need a fuel efficient car. r 
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Student: I see, so I might say that the Adapter pattern 
is the best structural pattern for changing an object’s 
interface. 

Master: Yes. We also can use categories for one more 
purpose: to launch into new territory; for instance, 

<l we really want to deliver a sports car with ferrari 
performance at miata prices.” 

Student: That sounds like a death trap. 

Master: I’m sorry, I did not hear you Grasshopper. 
Student: Uh, I said “I see that” 

Student: So categories give us a way to think about the 
way groups of patterns relate and how patterns within 
a group relate to one another. They also give us a way 
to extrapolate to new patterns. But why are there three 
categories and not four, or five? 

Master; Ah, like stars in the night sky, there are as many 
categories as you want to see. Three is a convenient 
number and a number that many people have decided 
makes for a nice grouping of patterns. But others have 
suggested four, five or more. 
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Thiwkiwg iw Patterns 


Contexts, constraints, forces, catalogs, classifications... boy, this 
is starting to sound mighty academic. Okay, all that stuff is 
important and knowledge is power. But, let’s face it, if you 
understand the academic stuff and don’t have the experience 
and practice using patterns, then it’s not going to make much 
difference in your life. 

Here’s a quick guide to help you start to think in patterns. What do 
we mean by that? We mean being able to look at a design and see 
where patterns naturally fit and where they don’t. 



oh PattcVhS 


Keep it simple (KISS) 

First of all, when you design, solve things in the simplest way possible. Your goal should be simplicity, not 
“how can I apply a pattern to this problem.” Don’t feel like you aren’t a sophisticated developer if you 
don’t use a pattern to solve a problem. Other developers will appreciate and admire the simplicity of your 
design. That said, sometimes the best way to keep your design simple and flexible is to use a pattern. 

Pesigw Patterns aren't a magic bullet; in fact theyVe wot even a bullet! 

Patterns, as you know, are general solutions to recurring problems. Patterns also have the benefit of being 
well tested by lots of developers. So, when you see a need for one, you can sleep well knowing many 
developers have been there before and solved the problem using similar techniques. 

However, patterns aren’t a magic bullet. You can’t plug one in, compile and then take an early lunch. To 
use patterns, you also need to think through the consequences on the rest of your design. 


You know you need a pattern whe^i... 

Ah... the most important question: when do you use a pattern? As you approach your design, introduce a 
pattern when you’re sure it addresses a problem in your design. If a simpler solution might work, give that 
consideration before you commit to using a pattern. 

Knowing when a pattern applies is where your experience and knowledge come in. Once you’re sure a 
simple solution will not meet your needs, you should consider the problem along with the set of constraints 
under which the solution will need to operate — these will help you match your problem to a pattern. If 
you’ve got a good knowledge of patterns, you may know of a pattern that is a good match. Otherwise, 
survey patterns that look like they might solve the problem. The intent and applicability sections of the 
patterns catalogs are particularly useful for this. Once you’ve found a pattern that appears to be a good 
match, make sure it has a set of consequences you can live with and study its effect on the rest of your 
design. If everything looks good, go for it! 
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There is one situation in which you’ll want to use a pattern even if a 
simpler solution would work: when you expect aspects of your system to 
vary. As we’ve seen, identifying areas of change in your design is usually a 
good sign that a pattern is needed. Just make sure you are adding patterns 
to deal with practical change that is likely to happen, not hypothetical change 
that may happen. 

Design time isn’t the only time you want to consider introducing patterns, 
you’ll also want to do so at refactoring time. 


Refactoring time is Patterns time! 

Refactoring is the process of making changes to your code to improve 
the way it is organized. The goal is to improve its structure, not change 
its behavior. This is a great time to reexamine your design to see if it 
might be better structured with patterns. For instance, code that is full 
of conditional statements might signal the need for the State pattern. Or, 
it may be time to clean up concrete dependencies with a Factory. Entire 
books have been written on the topic of refactoring with patterns, and as 
your skills grow, you’ll want to study this area more. 


Take out what you don't really weed. Pont be afraid 
to remove a design Pattern from your design. 

No one ever talks about when to remove a pattern. You’d think it was 
blasphemy! Nah, we’re all adults here; we can take it. 

So when do you remove a pattern? When your system has become 
complex and the flexibility you planned for isn’t needed. In other words, 
when a simpler solution without the pattern would be better. 


If you don't need it wow, don't do it wow. 

Design Patterns are powerful, and it’s easy to see all kinds of ways 
they can be used in your current designs. Developers naturally love to 
create beautiful architectures that are ready to take on change from any 
direction. 

Resist the temptation. If you have a practical need to support change in 
a design today, go ahead and employ a pattern to handle that change. 
However, if the reason is only hypothetical, don’t add the pattern, it is 
only going to add complexity to your system, and you might never need it! 
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Master and Student" 

Master: Grasshopper, your initial training is almost 
r complete. What are your plans? 

Student: I’m going to Disneyland! And, then I’m 
going to start creating lots of code with patterns! 

Master: Whoa, hold on. Never use your big guns unless you have to. 

Student: What do you mean, Master? Now that I’ve learned design 
patterns shouldrft I be using them in all my designs to achieve 
maximum power, flexibility and manageability? 

Master: No; patterns are a tool, and a tool that should only be used 
when needed. YotyVe also spent a lot of time learning design principles. 
Always start from your principles and create the simplest code you can 
that does the job. However, if you see the need fora pattern emerge, 
then use it. 

Student: So I shouldn't build my designs from patterns? 

Master: That should not be your goal when beginning a design. Let 
patterns emerge naturally as your design progresses. 

Student: If patterns are so great, why should I be so careful about 
using them? 

Master: Patterns can introduce complexity，and we never want 
complexity where it is not needed. But patterns are powerful when used 
where they are needed. As you already know, patterns are proven 
design experience that can be used to avoid common mistakes. They’re 
also a shared vocabulary for communicating our design to others. 

Student: Well, when do we know it’s okay to introduce design patterns? 

Master: Introduce a pattern when you are sure it’s necessary to solve a 
problem in your design, or when you are quite sure that it is needed to 
deal with a future change in the requirements of your application. 

Student: I guess my learning is going to continue even though I already 
understand a lot of patterns. 

Master: Yes, grasshopper; learning to manage the complexity and 
change in software is a life long pursuit. But now that you know a good 
set of patterns, the time has come to apply them where needed in your 
design and to continue learning more patterns. 

Student: Wait a minute, you mean I don’t know them ALL? 

Master: Grasshopper, you } ve learned the fundamental patterns; you Ye 
going to find there are many more, including patterns that just apply to 
particular domains such as concurrent systems and enterprise systems. 
But now that you know the basics, you’re in good shape to learn them! 
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Your Miwd ow Patterns 


The Beginner uses patterns everywhere. This is good: 
the beginner gets lots of experience with and practice using 
patterns. The beginner also thinks, “The more patterns I use, 
the better the design.” The beginner will learn this is not so, 
that all designs should be as simple as possible. Complexity 
and patterns should only be used where they are needed for 
practical extensibility. 


w | y\ttA B (or Hello World ” 


As learning progresses, the Intermediate mind 
starts to see where patterns are needed and 
where they aren’t. The intermediate mind still tries 
to fit too many square patterns into round holes, but 
also begins to see that patterns can be adapted to 
fit situations where the canonical pattern doesn’t fit. 


IHTERMEDIATE 

hlHD 

w A^|aybc I heed s S'mglc*tor> w 




BEGIHHER MIHD 


The Zen mind is able to see patterns where they fit naturally. 

The Zen mind is not obsessed with using patterns; rather it 
looks for simple solutions that best solve the problem. The Zen 
mind thinks in terms of the object principles and their trade-offs. 
When a need for a pattern naturally arises, the Zen mind applies 
it knowing well that it may require adaptation. The Zen mind 
also sees relationships to similar patterns and understands the 
subtleties of differences in the intent of related patterns. The 
“丁 his is a ha-tuval plate -for D 杜 o\ra 七 or ” Zen mind is also a Beginner mind —it doesn't let all that pattern 

knowledge overly influence design decisions. 


ZEH hlHD 
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rnSg 0 ^ ^ 伽灿 ⑽ ，ntroduce P* where the need 


Wait a minute; I’ve 
read this entire book and now 
you're telling me NOT to use 
patterns? 



Of course we want you to 
use Design Patterns! 

But we want you to be a good OO designer even 
more. 

When a design solution calls for a pattern, you get 
the benefits of using a solution that has been time 
tested by lots of developers. You’re also using a 
solution that is well documented and that other 
developers are going to recognize (you know, that 
whole shared vocabulary thing). 

However, when you use Design Patterns, there 
can also be a downside. Design Patterns often 
introduce additional classes and objects, and so 
they can increase the complexity of your designs. 
Design Patterns can also add more layers to your 
design, which adds not only complexity, but also 
inefficiency. 


Also, using a Design Pattern can sometimes be 
outright overkill. Many times you can fall back on 
your design principles and find a much simpler 
solution to solve the same problem. If that 
happens, don’t fight it. Use the simpler solution. 

Don’t let us discourage you, though. When a 
Design Pattern is the right tool for the job, the 
advantages are many. 
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VoWi forget the power of the 
shared vocabulary 

We’ve spent so much time in this book discussing OO nuts and bolts that it’s 
easy to forget the human side of Design Patterns - they don’t just help load 
your brain with solutions, they also give you a shared vocabulary with other 
developers. Don’t underestimate the power of a shared vocabulary, it’s one of 
the biggest benefits of Design Patterns. 

Just think, something has changed since the last time we talked about shared 
vocabularies; you’ve now started to build up quite a vocabulary of your own! 
Not to mention, you have also learned a full set of OO design principles from 
which you can easily understand the motivation and workings of any new 
patterns you encounter. 

Now that you’ve got the Design Pattern basics down, it’s time for you to 
go out and spread the word to others. Why? Because when your fellow 
developers know patterns and use a shared vocabulary as well, it leads to 
better designs, better communication and, best of all, it’ll save you a lot of 
time that you can spend on cooler things. 



five ways to share your vocabulary 


Top five ways to share your vocabulary 

1 In design meetings: When you meet with your team to discuss 

a software design, use design patterns to help stay-in the design” 
longer. Discussing designs from the perspective of Design Patterns 
and 00 principles keeps your team from getting bogged down in 
implementation details and prevent many misunderstandings. 

2 With other developers: Use patterns in your discussions with 

other developers. This helps other developers learn about new 
patterns and builds a community. The best part about sharing what 
you've learned is that great feeling when someone else "gets it!” 

3 In architecture documentation: When you write 
architectural documentation, using patterns will reduce the amount 
of documentation you need to write and gives the reader a clearer 
picture of the design. 

4 In code comments and naming conventions: When 
you're writing code, clearly identify the patterns you're using in 
comments. Also, choose class and methods names that reveal any 
patterns underneath. Other developers who have to read your 
code will thank you for allowing them to quickly understand your 
implementation. 

5 To groups of interested developers: Share your knowledge. 

Many developers have heard about patterns but don’t have a good 
understanding of what they are. Volunteer to give a brown-bag lunch 
on patterns or a talk at your local user group. 


Su^ih 乙七 
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Cruisin' Objectvillewith 
the frawg of Four 

You won’t find the Jets or Sharks hanging around Objectville, but 
you will find the Gang of Four. As you’ve probably noticed, you 
can’t get far in the World of Patterns without running into them. 
So, who is this mysterious gang? 

Put simply, “the GoF / 5 which includes Erich Gamma, Richard 
Helm, Ralph Johnson and John Vlissides, is the group of guys who 
put together the first patterns catalog and in the process, started an 
entire movement in the software field! 

How did they get that name? No one knows for sure; it’s just a 
name that stuck. But think about it: if you’re going to have a 
“gang element” running around Objectville, could you think of a 
nicer bunch of guys? In fact, they’ve even agreed to pay us a visit... 


TKc lauy^cd the so^-tv/avc 

pattev * 灼 s movement °^ C，rS 

Kavc made do>r>Viku-tioy>s, 

•mdud 叫 Wavd 

Bcdk, Jirw Copl'icn, ^v-ady ?>oocM f Bvudc 

A^dcvsoy>, RiAard Gabriel, Vo^ Lea, 
petev Codd) Pou^ SdKw'id't) "to 
jus-t a -fow- 




Today ^ 
there are more 
patterns than in the 
GoF book; learn about 
them as well. 


Shoot for practical > 
extensibility. Don’t 
provide hypothetical 
generality; be extensible 
, in ways that matter. 


广 Go for simplicity 
/ and don’t become over-excited. 
C If you can come up with a 
7 simpler solution without using a 
O pattern, then go for it. 


JoV^r\ \/l>ssidcs 


R^V^avd Q V 〜Ralph 

HcU 。 崎襄 JohhSoh 




Patterns are 
tools not rules - they 
need to be tweaked and 
adapted to 

. your problem. 〆 




patterns resources 


Your journey has just begun... 

Now that you’re on top of Design Patterns and ready to dig deeper, we’ve got three definitive 
texts that you need to add to your bookshelf... 


Design Patterns 

Elements of Reusable 
Object-Oriented Software 


Erich Ganima 
Richard Mfelm 
Ralph Ujhnson 
John Vlissides 





I 



The definitive Design Patterns text 

This is the book that kicked off the entire field of Design 
Patterns when it was released in 1995. You’ll find all the 
fundamental patterns here. In fact, this book is the basis for 
the set of patterns we used in Head First Design Patterns. 

You won’t find this book to be the last word on Design 
Patterns — the field has grown substantially since its 
publication - but it is the first and most definitive. 

Picking up a copy of Design Patterns is great way to start 
exploring patterns after Head First. 


ov (y^ ^ sV ' ov ■ 乇 . 


Chvisiophcv Alcxahdcv- mvchtcd 
patterns, y/hidh ihspived applying 

simibv solutiohs to so-p-tv/avc- 


The definitive Patterns texts 

Patterns didn’t start with the GoF; they started with 
Christopher Alexander, a Professor of Architecture 
at Berkeley — that’s right, Alexander is an architect, 
not a computer scientist. Alexander invented 
patterns for building living architectures (like 
houses, towns and cities). 

The next time you’re in the mood for some deep, 
engaging reading, pick up The Timeless Way of 
Building and ^4 Pattern Language. You’ll see the true 
beginnings of Design Patterns and recognize 
the direct analogies between creating “living 
architecture” and flexible, extensible software. 

So grab a cup of Starbuzz Coffee, sit back, and 
enjoy... 
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Conferences and Workshop! 


And if you’d like to get some face-to-face time with 
the patterns community, be sure to check out the 
many patterns related conferences and workshops. 
The Hillside site maintains a complete list. At 
the least you’ll want to check out OOPSLA, the 
ACM Conference on Object-Oriented Systems, 
Languages and Applications. 


Other Design Pattern resources 

You’re going to find there is a vibrant, friendly community of patterns 
users and writers out there and they’re glad to have you join them. 
Here’s a few resources to get you started... 



Websites 


The Portland Patterns Repository, run by 

Ward Cunningham, is a WIKI devoted to all 
things related to patterns. Anyone can participate. 
You’ll find threads of discussion on every topic 
you can think of related to patterns and OO 
systems. 

http : //c2.com/cgi/wiki?WelcomeVisitors 

The Hillside Group fosters common 
programming and design practices and provides 
a central resource for patterns work. The site 
includes information on many patterns-related 
resources such as articles, books, mailing lists and 
tools. 

http : //hillside.net/ 
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The Patterns Zoo 

As you’ve just seen, patterns didn’t start with software; they started 
with the architecture of buildings and towns. In fact, the patterns 
concept can be applied in many different domains. Take a walk 
around the Patterns Zoo to see a few... 




Architectural Patterns are 

used to create the living, 
vibrant architecture of 
buildings, towns, and cities. 
This is where patterns got 
their start. 



Habitat -fou^d \y\ build'my you 
like *to live *m> look a*t visit 


habitat sccy. 吒 avou^d 
3 - tier avdWi-tcdWcs, 

sewev sytews a 灼 d web. 



Application Patterns are 

patterns for creating 
system level architecture. 

Many multi-tier 
architectures fall into this 



category. 

Field «ote ： fAMC has bee« 

b>ovm •to ?ass W a« 




Domain-Specific Patterns Helf -Pmd a Siabrbi 

are patterns that concern JZBB 

problems in specific domains, 
like concurrent systems or 

real-time systems. _ 
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Business Process Patterns 

describe the interaction 
between businesses, customers 
and data, and can be applied 
to problems such as how 
to effectively make and 
communicate decisions. 





mcc-tihgs. 


Help -P'md a habi*tcl*t 
PcvcIoprwCh-t "team 
Cus-torwcv suppovt tcarw 


Organizational Patterns 

describe the structures 
and practices of human 
organizations. Most 
efforts to date have 



focused on organizations 
that produce and/or 
support software. 



User Interface 
Design Patterns 

address the 
problems of how to 
design interactive 
software programs. 



o( video dcsi^cvs, qUI 

buildcvs, a^d fv-od^evs. 


Field hotes ： please add youv obsewatiohs of domains hcvc- 


you are here 


605 




anti-patterns 


AnHihilating evil with Awti-Pattcrws 

The Universe just wouldn’t be complete if we had patterns and no 
anti-patterns, now would it? 

If a Design Pattern gives you a general solution to a recurring 
problem in a particular context, then what does an anti-pattern 



An Anti-Pattern tells you how to go from a problem 
to a BAD solution. 


You’re probably asking yourself, “Why on earth would anyone 
waste their time documenting bad solutions?” 

Think about it like this: if there is a recurring bad solution to a 
common problem, then by documenting it we can prevent other 
developers from making the same mistake. After all, avoiding bad 
solutions can be just as valuable as finding good ones! 

Let’s look at the elements of an anti-pattern: 


An anti-pattern tells you why a bad solution is 
attractive. Let’s face it, no one would choose a bad solution if 
there wasn’t something about it that seemed attractive up front. 
One of the biggest jobs of the anti-pattern is to alert you to the 
seductive aspect of the solution. 

An anti-pattern tells you why that solution in the long 
term is bad. In order to understand why it’s an anti-pattern, 
you’ve got to understand how it’s going to have a negative effect 
down the road. The anti-pattern describes where you’ll get into 
trouble using the solution. 

An anti-pattern suggests other patterns that are 
applicable which may provide good solutions. To be 

truly helpful an anti-pattern needs to point you in the right 
direction; it should suggest other possibilities that may lead to 
good solutions. 


Let’s have a look at an anti-pattern. 




An anti-pattern always 
looks like a gfooct solution, 
tut tken turns out to te 
a tact solution wken it is 
appliect. 

By ctocumentingf anti- 
patterns we lielp 
otkers to recognize tact 
solutions Wore tkey 
implement tkem. 

Like patterns, tkere 
are many types 
oi anti-patterns 
incluctingf ctevelopment, 
00, organizational, 
anct ctomain speciiic 
anti-patterns. 
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better living with patterns 


Here’s a 的 c^arwplc o( d sof*tv/a\rc develop 你⑶七扣 *ti 一 pa*btev^. 



vW like a Design Pat-tcvh, 
ah has a ha^e 


so wc ercaic a shared 
votabulavy. 


The problem a^d 乙 oivbc 乂 t 

jus 七 like a Pcsi^ Patten^ 
dcstirip-tioh. 




a*t*tvad*tWc. 


The bad, ye 七 a*t*tv-a^*tivc solu 七 icm. 





Example o( y/licvc "this ar\"ti — pattem 
has \)ttv\ observed. 



Aisf? - 1 Paftevs. 

Name: Golden Hammer 

Problem: You need to choose technologies for 
your development and you believe that exactly one 
technology must dominate the architecture. 

Context: You need to develop some new system 
or piece of software that doesn’t fit well with the 
technology that the development team is familiar with. 

Forces: 

• The development team is committed to the 
technology they know. 

• The development team is not familiar with 
other technologies. 

• Unfamiliar technologies are seen as risky. 

• It is easy to plan and estimate for 
development using the familiar technology. 

Supposed Solution: Use the familiar technology 
anyway. The technology is applied obsessively to 
many problems, including places where it is clearly 
inappropriate. 

Refactored Solution: Expanding the knowledge of 
developers through education, training, and book 
study groups that expose developers to new solutions. 

Examples: 

Web companies keep using and maintaining their 
internal homegrown caching systems when open 
source alternatives are in use. 


d\s6VASS\onS. 
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design toolbox 


綾 15 

Now，s 


Tools for your design Toolbox 


You’ve reached that point where you’ve outgrown us. 
Now’s the time to go out in the world and explore 
patterns on your own... 



:; E: 二:： si 

,ViOVAV 


ou-t tKc 
y/c II 

ftivc vou a Kcads 


BULLET POINTS 



Let Design Patterns emerge in 
your designs, don’t force them 
in just for the sake of using a 
pattern. 

Design Patterns aren’t set in 
stone; adapt and tweak them to 
meet your needs. 

Always use the simplest 
solution that meets your needs, 
even if it doesn’t include a 
pattern. 

Study Design Pattern catalogs 
to familiarize yourself with 
patterns and the relationships 
among them. 

Pattern classifications (or 
categories) provide groupings 
for patterns. When they help, 
use them. 

You need to be committed to 
be a patterns writer: it takes 
time and patience, and you 
have to be willing to do lots of 
refinement. 

Remember, most patterns you 
encounter will be adaptations 
of existing patterns, not new 
patterns. 

Build your team’s shared 
vocabulary. This is one of the 
most powerful benefits of using 
patterns. 

Like any community, the 
patterns community has its 
own lingo. Don’t let that hold 
you back. Having read this 
book, you now know most of it. 
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Leaving Objectville... 


better living with patterns 



Poy, if s been great having you in Objectville. 

We’re going to miss you, for sure. But don’t worry - before you know it, the 
next Head First book will be out and you can visit again. What’s the next book, 
you ask? Hmmm, good question! Why don’t you help us decide? Send email 
to booksuggestions@wickedlysmart.com. 


you are here 
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who does what? solution 


Exercise solutions 




Match each pattern with its description: 


Pattern 


Decprsttpr - 


St£tte 


Itersttpr 


Facade- 


Strgteg/^\j 

B-px/ 

Factory Medic 


OtserVer- 


lemplsite Metk>c 

C^niposite_ - 

Singleton 

Abstract Factory- 


Cpnimmicl ■ 


Description 


Wraps an ptject and provides a cll??erent 
Interface to ft. 

Subclasses decide fcpw Implement steps in 
m alg ； pr!tJini. 

Subclasses decide which concrete classes io 
create- 

Ensures one and only object Is created- 

Encapsulates Interctqngieakle beJiaVIprs and 
uses deleg ； qt!pii ip decide wfcicji Pnet9 use. 

Clients treqt collections P? objects and 
fncIIVIdual objects unl¥prml/. 

■ Encapsulates st^e-kased keJiaVIprs md uses 
deleg ； qt!oii switch ketWeen keJiaViPrs. 

"provides a way 19 traVerse a collection of 
objects Without exposing Its Implementatipn. 

〜 Simplifies the Interface a set P? closes. 

Wraps gn object 19 prpVIJe new keJiaVIpr. 

All^Ws a client ip create fetmllies objects 
Without specifying tWlr concrete classes ， 

All^Ws objects i9 te notified wjien st 批 e 
c^miges. 

Wraps an object to control access ip it. 
Encapsulates a request Qs object. 
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14 ^endix 


Appendix: Leftover Patterns 



Not everyone can be the most popular, a lot has changed in 
the last 10 years. Since Design Patterns: Elements of Reusable Object-Oriented 
Software first came out, developers have applied these patterns thousands 
of times. The patterns we summarize in this appendix are full-fledged, card- 
carrying, official GoF patterns, but aren’t always used as often as the patterns 
we’ve explored so far. But these patterns are awesome in their own right, and 
if your situation calls for them, you should apply them with your head held high. 
Our goal in this appendix is to give you a high level idea of what these patterns 
are all about. 


this is the appendix 
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bridge pattern 


fridge 

Use the Bridge Pattern to vary not only your 
implementations, but also your abstractions. 


A scenario 

Imagine you’re going to revolutionize “extreme 
lounging.” You’re writing the code for a new 
ergonomic and user-friendly remote control for 
TVs. You already know that you’ve got to use 
good OO techniques because while the remote is 


TW.S is ary abst^adtioyv. It toi*ld be 
扣 mtev-fade a*> abstvadt tiass. 




many times as usability data is collected on the remote 


control. 

So your dilemma is that the remotes are going to change and 
the TVs are going to change. You’ve already abstracted the user 
interface so that you can vary the implementation over the many 
TVs your customers will own. But you are also going to need 
to vary the abstraction because it is going to change over time as 
the remote is improved based on the user feedback. 


Ws\^ tw.s desi^ vav-Y 

the JM 山“*七 

wsev inte'r'fate- 


So how are you going to create an OO design that allows you 
to vary the implementation and the abstraction? 
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leftover patterns 


Why use the fridge Pattern? 

The Bridge Pattern allows you to vary the implementation and 
the abstraction by placing the two in separate class hierarchies. 


t\ass Wieraftht 



The velatioy>sW.\> 

the two is Yt^trytA io 

as 


—I ⑽ irbtioh 山 SS hicv-a^hy. 



RemoteControl 

implementor 

on(j 

off() 

setChannel(). 

II more methods 



ConcreteRemote 

currentStation 

on() 

off() 

setStation() 
nextChannel()-' 
previousChannel() 

II more methods 


Has-A 


implementor.tuneChannel(channel); 


All methods m the abs^attor. 

av-e i—eme 士 d terms A 


setChannel(currentStation + 1); 





RCA 


Sony 

on() 


on() 

off() 


off() 

tuneChannel() 


tuneChannel() 

II more methods 


II more methods 


t 

Coy\trtit subdlasscs avc implcmcr\*tcd m -tcvms Jc 
abs*tv*ad"tior\, 於 。七 


Now you have two hierarchies, one for the remotes and a separate one for platform 
specific TV implementations. The bridge allows you to vary either side of the two 
hierarchies independently. 


^Bridge Benefits - 

■ Decouples an implementation so that it is not bound 
permanently to an interface. 

■ Abstraction and implementation can be extended 
independently. 

■ Changes to the concrete abstraction classes don’t 
affect the client. 


「Bridge Uses and Drawbacks - 

_ Useful in graphic and windowing systems that need to 
run over multiple platforms. 

■ Useful any time you need to vary an interface and an 
implementation in different ways. 

■ Increases complexity. 
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builder pattern 


Guilder 

Use the Builder Pattern to encapsulate the construction of 
a product and allow it to be constructed in steps. 


A scenario 

You’ve just been asked to build a vacation planner for Patternsland, a new theme 
park just outside of Objectville. Park guests can choose a hotel and various types of 
admission tickets, make restaurant reservations, and even book special events. To create 
a vacation planner, you need to be able to create structures like this: 

vacation is farmed 
over some |r»uirwbcv o-f days. 



/I\ 

OQQ 









You need a flexible design 

Each guest’s planner can vary in the number of days and types of activities it includes. 
For instance, a local resident might not need a hotel, but wants to make dinner and 
special event reservations. Another guest might be flying into Objectville and needs a 
hotel, dinner reservations, and admission tickets. 

So, you need a flexible data structure that can represent guest planners and all their 
variations; you also need to follow a sequence of potentially complex steps to create the 
planner. How can you provide a way to create the complex structure without mixing it 
with the steps for creating it? 
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Why use the Guilder Pattern? 

Remember Iterator? We encapsulated the iteration into a separate 
object and hid the internal representation of the collection from the 
client. It’s the same idea here: we encapsulate the creation of the 
trip planner in an object (let’s call it a builder), and have our client 
ask the builder to construct the trip planner structure for it. 


The dic^-t uses 



— Builder Benefits - 

■ Encapsulates the way a complex object is 
constructed. 

■ Allows objects to be constructed in a multistep and 
varying process (as opposed to one step factories). 

■ Hides the internal representation of the product from 
the client. 

■ Product implementations can be swapped in and out 
because the client only sees an abstract interface. 


「Builder Uses and Drawbacks - 

■ Often used for building composite structures. 

■ Constructing objects requires more domain 
knowledge of the client than when using a Factory. 
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chain of responsibility pattern 


Chain of Responsibility 

Use the Chain of Responsibility Pattern when you want to 
give more than one object a chance to handle a request. 


A scenario 

Mighty Gumball has been getting more email 
than they can handle since the release of the 
Java-powered Gumball Machine. From their 
own analysis they get four kinds of email: fan 
mail from customers that love the new 1 in 10 
game, complaints from parents whose kids 
are addicted to the game and requests to put 
machines in new locations. They also get a fair 
amount of spam. 

All fan mail needs to go straight to the CEO, 
all complaints go to the legal department and 
all requests for new machines go to business 
development. Spam needs to be deleted. 

Your task 

Mighty Gumball has already written some AI 
detectors that can tell if an email is spam, fan 
mail, a complaint, or a request, but they need you 
to create a design that can use the detectors to 
handle incoming email. 


you’ve 
got to help us 
deal with the flood 
of email were getting 
since the release of 
the Java Gumball 
Machine. 
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How to use the Chain of Responsibility Pattern 


With the Chain of Responsibility Pattern, you create a chain of objects 
that examine a request. Each object in turn examines the request and 
handles it, or passes it on to the next object in the chain. 


at-b as a a: 

a s«*ttessov objett 1+ 

cby\ *bV^c > 

it docs ； 。从 c 一 ， 1 七 

to 


1-ts sutdcssov. 



As email is received, it is passed to the first handler: the 
SpamHandler. If the SpamHandler can’t handle the request, 
it is passed on to the FanHandler. And so on... 

UcM t^\\ ?asscd to 
i\, t 



tma'il «s ^o-t V>ay»dlcd >*f '"t 
-falls o-f-f -tV>c tv\d o( i\\t dWm 
一 al*tV>oiA 咖 Y olA 

•• 叫 >lcmwb a - all V>ay>dlcv. 



r^\ 

\ /Complaint 丨 ^ "V [ NewLoc 
— Handler Handler 


—— Chain of Responsibility Benefits - 

■ Decouples the sender of the request and its 
receivers. 

■ Simplifies your object because it doesn’t have to 
know the chain’s structure and keep direct references 
to its members. 

■ Allows you to add or remove responsibilities 
dynamically by changing the members or order of the 
chain. 


「Chain of Responsibility Uses and Drawbacks^ 

■ Commonly used in windows systems to handle 
events like mouse clicks and keyboard events. 

■ Execution of the request isn’t guaranteed; it may fall 
off the end of the chain if no object handles it (this can 
be an advantage or a disadvantage). 

■ Can be hard to observe the runtime characteristics 
and debug. 
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flyweight pattern 


Flyweight 

Use the Flyweight Pattern when one instance of a class 
can be used to provide many “virtual instances.” 

A scenario 

You want to add trees as objects in your hot new landscape design application. In 
your application, trees don’t really do very much; they have an X-Y location, and they 
can draw themselves dynamically, depending on how old they are. The thing is, a user 
might want to have lots and lots of trees in one of their home landscape designs. It 
might look something like this: 



Your big client’s dilemma 

You’ve just landed your “reference account.” That key client 
you’ve been pitching for months. They’re going to buy 1,000 
seats of your application, and they’re using your software 
to do the landscape design for huge planned communities. 
After using your software for a week, your client is 
complaining that when they create large groves of trees, the 
app starts getting sluggish... 


Ty e . : , 
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Why use the Flyweight Pattern? 

What if, instead of having thousands of Tree objects, you 
could redesign your system so that you’ve got only one 
instance of Tree, and a client object that maintains the state 
of ALL your trees? That’s the Flyweight! 


Ail tKe sta-te, ^ A LL 

yowt Tvee 

objetts, is stored 
this zP-array- 



㈣ 产〜 


Tree 


display(x, y, age) { 
// use X-Y coords 
// & complex age 
// related calcs 





Flyweight Benefits - 

Reduces the number of object instances at runtime ； 
saving memory. 

Centralizes state for many “virtual” objects into a 
single location. 


— Flyweight Uses and Drawbacks - 

■ The Flyweight is used when a class has many 
instances, and they can all be controlled identically. 

■ A drawback of the Flyweight pattern is that once 
you’ve implemented it, single, logical instances of the 
class will not be able to behave independently from 
the other instances. 
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interpreter pattern 


Interpreter 

Use the Interpreter Pattern to build an 
interpreter for a language. 

A scenario 

Remember the Duck Pond Simulator? You have a hunch it 
would also make a great educational tool for children to learn 
programming. Using the simulator, each child gets to control one 
duck with a simple language. Here’s an example of the language: 


right; 

while (daylight) 
quack; 





fly; 〆 A all day … 



... 扣 cUh eh ，止 


O 



Now, remembering how to create grammars from one of your old 
introductory programming classes, you write out the grammar: 




rcY' 

expression : := <command> | <sequence> | <repetition> 
sequence :: = <expression> ';' <expression> 
command :: = right | quack | fly 

repetition :: = while '(' <variable> ') ' <expresion> 
variable :: = [A-Z,a-z]+ 




^ is d 

set c%pv-cssio^s 
sepav-a-ted by 
scmidolor\s. 


1 /Vc Kavc 

fV (\\Aat\c, av\d -fly- 

V A while is ., 

a ^^i-tional variable 

扣 d an expir ess i w . 


Now what? 

You’ve got a grammar; now all you need is a way to represent and 
interpret sentences in the grammar so that the students can see the 
effects of their programming on the simulated ducks. 
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How to implement an interpreter 

When you need to implement a simple language, the 
Interpreter Pattern defines a class-based representation for its 
grammar along with an interpreter to interpret its sentences. 
To represent the language, you use a class to represent each 
rule in the language. Here’s the duck language translated 
into classes. Notice the direct mapping to the grammar. 



To interpret the language, call the interpret。method on each 
expression type. This method is passed a context — which 
contains the input stream of the program we’re parsing — and 
matches the input and evaluates it. 


—— Interpreter Benefits - 

■ Representing each grammar rule in a class makes 
the language easy to implement. 

■ Because the grammar is represented by classes, you 
can easily change or extend the language. 

■ By adding additional methods to the class structure, 
you can add new behaviors beyond interpretation, 
like pretty printing and more sophisticated program 
validation. 


^Interpreter Uses and Drawbacks - 

■ Use interpreter when you need to implement a 
simple language. 

■ Appropriate when you have a simple grammar and 
simplicity is more important than efficiency. 

■ Used for scripting and programming languages. 

■ This pattern can become cumbersome when the 
number of grammar rules is large. In these cases a 
parser/compiler generator may be more appropriate. 
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mediator pattern 


Mediator 

Use the Mediator Pattern to centralize complex 
communications and control between related objects. 

A scenario 

Bob has a Java-enabled auto-house, thanks to the good folks at HouseOfTheFuture. 
All of his appliances are designed to make his life easier. When Bob stops hitting the 
snooze button, his alarm clock tells the coffee maker to start brewing. Even though 
life is good for Bob, he and other clients are always asking for lots of new features: 
No coffee on the weekends... Turn off the sprinkler 15 minutes before a shower is 
scheduled... Set the alarm early on trash days... 




CoffeePot 


onEvent() { 
checkCalendar() 
checkAlarm() 
//do more stuff 


Sprinkler 


onEvent() { 
checkCalendar() 
checkShower() 
checkTemp() 
checkWeather() 
//do more stuff 


HouseOfTheFuture’s dilemma 

It’s getting really hard to keep track of which rules reside in which objects, and how 
the various objects should relate to each other. 
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Mediator in action... 

With a Mediator added to the system, all 
of the appliance objects can be greatly 
simplified: 

■ They tell the Mediator when their state 
changes. 

■ They respond to requests from the 
Mediator. 

Before adding the Mediator, all of the 
appliance objects needed to know about each 
other... they were all tightly coupled. With the 
Mediator in place, the appliance objects are 
all completely decoupled from each other. 

The Mediator contains all of the control 
logic for the entire system. When an existing 
appliance needs a new rule, or a new 
appliance is added to the system, you’ll know 
that all of the necessary logic will be added to 
the Mediator. 


Mediator Benefits 


Increases the reusability of the objects supported b\ 
the Mediator by decoupling them from the system. 
Simplifies maintenance of the system by centralizing 
control logic. 

Simplifies and reduces the variety of messages sen 


between objects in the system. 
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— Mediator Uses and Drawbacks - 

■ The Mediator is commonly used to coordinate related 
GUI components. 

■ A drawback of the Mediator pattern is that without 
proper design, the Mediator object itself can become 
overly complex. 
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memento pattern 


Memewto 

Use the Memento Pattern when you need 
to be able to return an object to one of its 
previous states; for instance，if your user 
requests an 66 undo.” 


A scenario 

Your interactive role playing game is hugely successful, 
and has created a legion of addicts, all trying to get 
to the fabled “level 13. 55 As users progress to more 
challenging game levels, the odds of encountering 
a game-ending situation increase. Fans who have 
spent days progressing to an advanced level are 
understandably miffed when their character gets snuffed, 
and they have to start all over. The cry goes out for a 
“save progress” command, so that players can store their 
game progress and at least recover most of their efforts 
when their character is unfairly extinguished. The 
“save progress” function needs to be designed to return 
a resurrected player to the last level she completed 
successfully. 



624 


appendix 



leftover patterns 


The Memewtoatwork 

The Memento has two goals: 

■ Saving the important state of a system’s key object. 

■ Maintaining the key object’s encapsulation. 


Keeping the single responsibility principle in mind, it’s also 
a good idea to keep the state that you’re saving separate 
from the key object. This separate object that holds the 
state is known as the Memento object. 


GameMeme 门 to 

< —— 

savedGameState 






lA/hile this \^i a 

rsohu Cl •咖七 

V>as v>o autss io 


Client 


// when new level is reached 
Object saved = 

(Object) mgo.getCurrentState(); 

//when a restore is required 
mgo.restoreState(saved); 


MasterGameObject 


gameState 

」 

Object getCurrentState() { 

// gather state 
return(gameState); 

} 

restoreState(Object savedState) { 

// restore state 

} 

//do other game stuff 



Memento Benefits - 

Keeping the saved state external from the key object 
helps to maintain cohesion. 

Keeps the key object’s data encapsulated. 

Provides easy-to-implement recovery capability. 


Memento Uses and Drawbacks - 

The Memento is used to save state. 

A drawback to using Memento is that saving and 
restoring state can be time consuming. 

In Java systems, consider using Serialization to save 
a system’s state. 
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prototype pattern 


Prototype 

Use the Prototype Pattern when creating an 
instance of a given class is either expensive or 
complicated. 

A scenario 

Your interactive role playing game has an insatiable appetite for monsters. As your 
heros make their journey through a dynamically created landscape, they encounter 
an endless chain of foes that must be subdued. You’d like the monster’s characteristics 
to evolve with the changing landscape. It doesn’t make a lot of sense for bird-like 
monsters to follow your characters into underseas realms. Finally, you’d like to allow 
advanced players to create their own custom monsters. 
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Prototype to the rescue 


The Prototype Pattern allows you to make new instances by 
copying existing instances. (In Java this typically means using 
the cloneQ method, or de-serialization when you need deep 
copies.) A key aspect of this pattern is that the client code can 
make new instances without knowing which specific class is 
being instantiated. 


«interface» 

Mo/isfer* 






WellKnownMonster 


一 


DynamicPIayerGeneratedMonster 


一 


MonsterMaker 


makeRandomMonster() { 

Monster m = 

MonsterRegistry.getMonster(); 


MonsterRegistry 


Monster getMonster() { 

// find the correct monster 
return correctMonster.clone(); 


.The died y>eeds a ^ moyjstrr 
a?? ro ? v\ate to the 

situation ( 丁以以⑽“严广 
krnd he i 


The ^ds the 


OhC- 


Prototype Benefits - 

Hides the complexities of making new instances from 
the client. 

Provides the option for the client to generate objects 
whose type is not known. 

In some circumstances, copying an object can be 
more efficient than creating a new object. 


— Prototype Uses and Drawbacks - 

■ Prototype should be considered when a system must 
create new objects of many types in a complex class 
hierarchy. 

■ A drawback to using the Prototype is that making a 
copy of an object can sometimes be complicated. 
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visitor pattern 


Visitor 

Use the Visitor Pattern when you want to 
add capabilities to a composite of objects 
and encapsulation is not important. 


A scenario 

Customers who frequent the Objectville Diner and Objectville 
Pancake House have recently become more health conscious. They 
are asking for nutritional information before ordering their meals. 
Because both establishments are so willing to create special orders, 
some customers are even asking for nutritional information on a 
per ingredient basis. 


Lou’s proposed solution: 


Menu 



Mel’s concerns... 

“Boy，it seems like we’re opening Pandora’s box. Who knows what 
new method we’re going to have to add next, and every time we 
add a new method we have to do it in two places. Plus, what if 
we want to enhance the base application with, say, a recipes class? 
Then we’ll have to make these changes in three different places."” 
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The Visitor drops by 


The Visitor must visit each element of the Composite; that 
functionality is in a Traverser object. The Visitor is guided by the 
Traverser to gather state from all of the objects in the Composite. 
Once state has been gathered, the Client can have the Visitor perform 
various operations on the state. When new functionality is required, 
only the Visitor must be enhanced. 


Cli^vt asks 
■bhe \/isi*tov* *to yb 
七 iern -fv-om 

Comfosi-bc s*brud 七 uve … 
New methods be 
added io V\^\ior 
v/i-b^ou-b a-f-fcdtmj 
Comfosi-tc- 



The \/isiW ««ds to W able to tall 

aetStateO atross Masses, ,s 

i\xt to use. 


All "these Composite 
classes have *to do is add 
a ytSta 七 eO mc-tliod 
(di^d t\o{, v/oirvy abou*t 
ilicmsclvcs). 


a^eO 


-> 


/^X. ? 

'V 气 


Menultem 




The Tv-aversev- kr\oY/s V>ov/ to 

au,dc \/'»s»tov 

tKc Composite stru^Wc- 


Ingredient 



— Visitor Benefits - 


~~Visitor Drawbacks - 

■ Allows you to add operations to a Composite 


■ The Composite classes’ encapsulation is broken 

structure without changing the structure itself. 


when the Visitor is used. 

■ Adding new operations is relatively easy. 


■ Because the traversal function is involved, changes to 

■ The code for operations performed by the Visitor is 
centralized. 


the Composite structure are more difficult. 
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Command Pattern, continued 
logging requests 229 
macro command 224 
Null Object 214 
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undo 216, 220, 227 
Composite Pattern 
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class diagram 358 
combining patterns 513 
composite behavior 363 
default behavior 360 
defined 356 
interview 376-377 
safety 367 

safety versus transparency 515 
transparency 367, 375 
composition 23, 85, 93, 247, 309 
compound pattern 500, 522 
controlling access 460. See also Proxy Pattern 
creating objects 134 

crossword puzzle 33, 76,163, 187, 231, 271, 310, 378, 
490 

cubicle conversation 55, 93, 195, 208, 387, 397,433, 
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class diagram 91 
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defined 91 

disadvantages 101, 104 


fireside chat 252-253 
interview 104 
introduction 88 
in Java I/O 100-101 
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Dependency Inversion Principle 139-143 
and the Hollywood Principle 298 
Design Patterns 
Abstract Factory Pattern 156 
Adapter Pattern 243 
benefits 599 
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Builder Pattern 614-615 
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Command Pattern 206 
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defined 579,581 
discover your own 586-587 
Facade Pattern 264 
Factory Method Pattern 134 
Flyweight Pattern 618-619 
Interpreter Pattern 620-621 
Iterator Pattern 336 
Mediator Pattern 622-623 
Memento Pattern 624—625 
Null Object 214 
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Observer Pattern 51 
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Prototype Pattern 626-627 
Proxy Pattern 460 
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Design Principles. See Object Oriented Design Principles 

Design Puzzle 25, 133, 279, 395,468, 542 

Design Toolbox 32, 74,105, 162, 186, 230, 270, 311 ， 
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DJ View 534 

domain specific patterns 604 
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encapsulating iteration 323 
encapsulating method invocation 206 
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encapsulating object creation 114, 136 
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advantages 260 
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introduction 258 
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class diagram 156-157 
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defined 134 
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up close 125 
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defined 117 
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Johnson, Ralph 601 

K 

KISS 594 
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Law of Demeter. See Principle of Least Knowledge 

lazy instantiation 177 
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magic bullet 594 

master and student 23, 30, 85, 136, 592,596 
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introduction 529 
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ready-bake code 564-576 
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up close 530 
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Null Object 214,372 

0 

Objectville Diner 26, 197, 316, 628 
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combining patterns 516 
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defined 51-52 
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Five minute drama 48 
introduction 44 
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and Decorator Pattern 471, 472473 
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exercise 482 
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java.lang.reflect.Proxy 474 
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variants 471 
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And now, a final word from Head First Labs... 

Our world class researchers are working day and night in a mad race to 
uncover the mysteries of Life, the Universe and Everything-before it's too late. 
Never before has a research team with such noble and daunting goals been 
assembled. Currently, we are focusing our collective energy and brain power on 
creating the ultimate learning machine. Once perfected, you and others will join 
us in our quest! 

You're fortunate to be holding one of our first protoypes in your hands. But only 
through constant refinement can our goal be achieved. We ask you, a pioneer 
user of the technology, to send us periodic field reports of your progress, at 
fieldreports@headfirstlabs.com 


O 



And next time you’re in Objectville, 
drop by and take one of our behind 
the scenes laboratory tours. 


o 






Now that you’ve applied the Head First approach to 
Design Patterns, why not apply it to the rest of your life? 

Come join us at the Head First Labs Web site, our virtual 
hangout where you’ll find Head First resources including 
podcasts, forums, code and more. 

But you won’t just be a spectator; we also encourage you to 
join the fun by participating in discussions and brainstorming. 


— What’s in it for you? - 

■ Get the latest news about what’s 
happening in the Head First World. 

■ Participate in our upcoming books and 
technologies. 

■ Learn how to tackle those tough 
technical topics (say that three times fast) 
in as little time as possible. 

■ Look behind the scenes at how Head 
First books are created. 

■ Meet the Head First authors and the 
support team who keep everything 
running smoothly. 

■ Why not audition to be a Head First 
author yourself? 


http://www.headfirstlabs.com 
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